We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi Experts,
In CMSIS RTX how the mutex and binary semaphore is handled ?
For example, in case of mutex is locked for some hardware peripheral drivers whether the task switch will be disabled ? or by any other means ?
Also where the binary semaphore should be used and where the mutex should be used ?
The documentation explains some aspects already:
Q: ... in case of mutex is locked ... whether the task switch will be disabled ?
A: osMutexWait contains.... While the system waits the thread that is calling this function is put into the state WAITING.
Thread states are described under Thread management. But I agree, it has room for improvements.
A Mutex is simpler (only ON/OFF) than a semaphore but the basic functionality is identical. Semaphores can counting (binary is with count=1) and be released from IRQ which is not possible for a Mutex.
I hope this clarifies your questions.
Hi Reinhard,
Thanks for the reply.
Consider thread A is having higher priority and thread B is having least priority. Now thread B is executing and locks the mutex for a peripheral driver. Now the interrupt occurs which triggers thread A and due to preemptive nature thread A activates. Now when thread A is trying to access the same mutex locked peripheral driver of thread B then thread A will be put into waiting state.
This is my understanding from your answer. Correct me if I am wrong.
Regards,
Techguyz
Now when thread A is trying to access the same mutex locked peripheral driver of thread B then thread A will be put into waiting state.
Yes, that is correct.
Note that CMSIS RTOS RTX also implements Priority Inversion. Refer to the documentation ..\CMSIS/RTOS/RTX/Doc/_theory.html#PriorityInversion
Yeah thats what I exactly want to ensure. Its priority inversion
Thanks for your valuable time.