>>>>> "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 ...
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.
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.
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."
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
