You are not logged in.
Pages: 1
Tread A locks X and then tries to take Y.
Thread B locks Y and then tries to take X.
Result: Deadlock.
Deadlocks can always happen when a thread takes more than one lock and
not all threads take all locks in the same order (no global lock ordering).
Offline
There are some mutex types where if a thread already has the mutex locked, and tries to lock it a second time, the thread will deadlock with itself. Those mutex types are used for best (i.e. slightly better) performance, but of course you have to be very careful when using them not to trip over your own feet.
The smarter kind of mutex (that keeps track of whether the locking thread has already locked the mutex, and if so, just increments a counter instead of putting the thread to sleep) is called a recursive mutex, and is less tricky to use.
(btw: as for why a thread would want to lock a mutex more than once... imagine a function that needs to serialize access to some data, but can be called both from contexts where the mutex is already locked, and contexts where it isn't locked. The easiest way to implement that function is to just always lock the mutex, even if it already is locked. The other way would be to check if the mutex is not locked, and if it isn't, lock it, but that's more complex and might expose you to a race condition if the mutex's locked-state changes after you do the is-locked check, but before you lock it)
Offline
Pages: 1