|
![](/i/fill.gif) |
Stefan Viljoen schrieb:
> Invisible wrote:
>
>> My point is, you can't just go "I've got lock 7 and lock 13, and now I
>> need lock 2, so I'll just release lock 7 and lock 13, then take lock 2
>> and take back lock 7 and lock 13". In between releasing the locks and
>> taking them back, something could change. You need a better plan than
>> that.
>
> Isn't this what a mutex (like it is implemented in the Linux kernel) is for?
With a mutex /being/ a lock, it doesn't get you out of the dilemma:
(1) Locks can create deadlocks.
(2) Deadlocks can be prevented by numbering the locks, and emposing the
constraint that a program cannot acquire a "lower" lock than the
"highest" one it currently owns, prevents deadlocks for sure.
(3) With this locking scheme, a program that has acquired lock X, done
some computations on the data read while holding the lock, possibly even
written other data, and is now coming to the conclusion that it needs to
acquire lock X-N, can do nothing but rollback to the state before it
acquired lock X, acquire lock X-N, and then acquire lock X again and
re-do all the computations, because the data the previous run was based
on might have been changed in the meantime.
So if performance is an issue, and it is not known beforehand what locks
may be required to complete the operation, this locking concept is
usually not an option.
Post a reply to this message
|
![](/i/fill.gif) |