How can/In what cases can a mutex be locked multiple times in the same thread?

Question

I do not understand the use of a mutex if it can be recursively locked by a thread. Why would anyone want to recursively lock the mutex ? In what cases will they use this ?

Answer 1

I do not understand the use of a mutex if it can be recursively locked by a thread.

A mutex is used to provide mutually exclusive access to a resource. In other words, only one thread (or "agent") should be able to access a resource at a time. Therefore, if a thread has taken a mutex, then it already has exclusive access to the resource, so there is no harm in allowing it to take the mutex again.

A recursive mutex is still useful since it still provides the semantics of exclusive access. While Thread 1 can take a mutex it already has, Thread 2 is still prevented from taking the mutex and accessing the resource at the same time as Thread 1.

Why would anyone want to recursively lock the mutex ?

For convenience: if my thread accesses a resource in a few different classes, each of them can acquire and release the mutex independently and in a nested manner without having to worry about each other. This could be seen as laziness or poor design, but this is an advantage over non-recursive mutexes that cause deadlock when a thread tries to take a mutex it already owns.

Answer 2

It seems you're asking for a possible use case for a reentrant lock. One would be in the case of using a callback to something. You might have a method which locks an object, and then calls something else, providing a callback with access to this object. If another method is called on this object it might also want to obtain the lock. It's perfectly safe for them both to have the lock, there's no way both can be operating concurrently, they're in the same thread.