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