At 09:43 PM 9/9/00 -0400, Chaim Frenkel wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> Right, but databases are all dealing with mainly disk access. A 1ms lock
>DS> operation's no big deal when it takes 100ms to fetch the data being
>locked.
>DS> A 1ms lock operation *is* a big deal when it takes 100ns to fetch the
>data
>DS> being locked...
>
>Actually, even a database can't waste too much time on locks, not when there
>may be thousands or millions of rows effected. But ...
but... it does. The time isn't wasted, but it is spent. It has to be.
Locking things in a relational database with ACID guarantees isn't cheap.
Records, being disk based with rollback guarantees, are significantly
heavier-weight than perl variables.
>DS> Correctness is what we define it as. I'm more worried about expense.
>
>DS> Detecting deadlocks is expensive and it means rolling our own locking
>DS> protocols on most systems. You can't do it at all easily with PThreads
>DS> locks, unfortunately. Just detecting a lock that blocks doesn't cut it,
>DS> since that may well be legit, and doing a scan for circular locking
>issues
>DS> every time a lock blocks is expensive.
>
>DS> Rollbacks are also expensive, and they can generate unbounded amounts of
>DS> temporary data, so they're also fraught with expense and peril.
>
>Then all "we" are planning on delivering is correctness with a possiblity
>of deadlocks with no notification.
At the moment, yup. I'd like otherwise, and I don't mind planning for it
(like giving lock a return value), but I think you'll find it rather
difficult and pricey.
>Is deadlock detection really that expensive? The cost would be born by
>the thread that will be going to sleep. Can't get lock, do the scan.
First, you don't scan every block. That's really expensive. I'm not sure
how things like Oracle do it, but VMS' lock manager only scans once a
second if there are blocked locks.
Secondly, the cost is borne by the entire system. Scanning a tree of locks
can be expensive. Depending on how many threads and how many locks
outstanding, you have a potentially very large list of things to go
through. That takes CPU time, memory, and cache space.
>I really think we will have to do it. And we should come up with the
>deadlock resolution. I don't think we will fly without it. We are going
>to be deluged with reports of "my program hangs. Bug in locking."
Yup. That's not at all uncommon with threads. :(
Adding in read/write locks and trylocks will help. Full thread deadlock
detection means tossing out POSIX's mutex scheme and rolling our own, and
doing that even close to efficiently is very platform-dependent and
error-prone. I'd rather not if we could manage it. (You can't, for example,
smack a thread blocked waiting on a mutex)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
