That is the very use case for a mutex.
To protect something use a mutex. And if done right (using correct lock/unlock pairing) there canât be an unexpected lock (forever).
Also a recursive mutex can be used ⌠recursively (in a single task, of course).
It means if (here: accidentally) called twice in a task it doesnât lock 2nd time.
This might be needed sometimes due to software structuring, but Iâd try to avoid it.
The classic case is malloc_lock. If you implement that as a non recursive mutex, it may indeed deadlock (really deadlock) the calling task. The C runtime libs mac try to claim the lock twice - first time when malloc() is being called, second time when under low memory conditions the code calls sbrk() which calls malloc_lock() again. I debugged that a while ago.
Yes maybe I will change it from binary semaphore to a mutex. But the codebase consists of lots of semaphores for resource protection. Donât know why though.
May be because the software was originally written for another RTOS that had a naming mĂsmatch and overused semaphores. Kadakâs AMX was such a case; they had two different kinds of semaphores (one called resource semaphores, the other counting semaphores) one of which was really a mutex. Nomenclature in synchronization is historically weird.
Sorry - thatâs bad code ⌠After reading the mutex docs youâll also see that mutexes support priority inheritance to avoid priority inversion effects. Usually and also FreeRTOS semaphores donât support this.
Correction:
Instead of it doesnât lock 2nd time I should have written that it doesnât block 2nd time. The matching lock/unlock pairing is of course still needed also for a recursive mutex.
ok, donât think recursive mutex is a good use here, I just want to take the semaphore/mutex and if the code tries to take it again it wont be blocked.
Donât want to take it x times and then give it x times.
But thanks a lot guys! Really appreciate your answers!
That doesnât sound like any functionality I have seen in any version of a semaphore or have seen a need for.
Either I am in a nested call where I will release the mutex once for every time I took it, or I have code that stops taking it again. If the code knows enough to not release the semaphore because it is needed elsewhere still, it knows enough that it doesnât need to take it.