Page 1 of 1
Mutex behaviour question
Posted: Wed May 29, 2024 10:59 pm
by 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))
Re: Mutex behaviour question
Posted: Thu May 30, 2024 7:21 am
by STARGÅTE
jassing wrote: Wed May 29, 2024 10:59 pm
Is this expected/as-designed?
Yes.
Re: Mutex behaviour question
Posted: Thu May 30, 2024 8:43 am
by Caronte3D
So... PB uses "Recursive Mutex"... Interesting
Re: Mutex behaviour question
Posted: Thu May 30, 2024 8:49 am
by Fred
Yes, we use recursive mutex
Re: Mutex behaviour question
Posted: Thu May 30, 2024 4:01 pm
by jassing
Thanks! Just wanted to be sure I could rely on it, it was unexepected.
Re: Mutex behaviour question
Posted: Thu May 30, 2024 4:43 pm
by 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.
Re: Mutex behaviour question
Posted: Thu May 30, 2024 6:28 pm
by 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.
Re: Mutex behaviour question
Posted: Thu May 30, 2024 7:35 pm
by Caronte3D
skywalk wrote: Thu May 30, 2024 4:43 pm
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.