Mutex behaviour question

[jassing]

Is this expected/as-designed?

Code: Select all

h=CreateMutex()

Procedure test( h )
  LockMutex(h)
  Debug "t1"
  LockMutex(h)
  Debug "t2"
EndProcedure

LockMutex(h)
Debug "M1"
LockMutex(h)
Debug "M2"

UnlockMutex(h) : UnlockMutex(h) ; both are required.  It acts like a semaphore in this regard.	
WaitThread(CreateThread(@test(),h))

[STARGÅTE]

Is this expected/as-designed?

Yes.

[Caronte3D]

So... PB uses "Recursive Mutex"... Interesting

[Fred]

Yes, we use recursive mutex

[jassing]

Thanks! Just wanted to be sure I could rely on it, it was unexepected.

[skywalk]

Interesting, I primarily use semaphores, but what I read says recursive mutexes are not preferred and rarely adopted.
There are small code cases where a recursive mutex can prevent a deadlock, but the deadlock was only possible due to a bad algorithm.

Anyway, it is worth documenting this within the thread library help.

[STARGÅTE]

The fact that the Mutex can be locked multiple times (and unlocked the same multiple times) allows the call of procedures which contain a Lock/Unlock block individually but also nested.

For example, you have a mutex protected list and define a procedure which sorts all elements.
Of cause, this procedure need a Lock/Unlock.
But you want to define an other procedure which also locks the mutex but calls the sorting procedure as well.
Therefore, the Lock-counter in Mutex is helpful.

[Caronte3D]

Anyway, it is worth documenting this within the thread library help.

+1000

If I was know about it's recursive, I could use a OutputDebugString_ for each Mutex and UnMutex so I know if a random deadlock is because a non paired mutex.