Mutext and semaphore

From: http://www.cppblog.com/martin/archive/2009/03/18/hello.html

"What is the difference between mutext and semaphore? "This is a short and powerful question, but it is quite difficult to answer. Even experienced real-time operating system (RTOs) users have difficulties in distinguishing how to correctly use mutex and semaphore.

However, this is unfortunate and dangerous, because none of the two native RTOS will cause unexpected errors in the embedded system, especially when these systems are products related to life security.
The absurd saying about mutex and semaphore is that they are similar and even interchangeable. the correct fact is that although mutex and semaphore have similarities in their execution, we should treat them differently when using them.
The most common (but incorrect) answer is: mutex and semphore are very similar. There is only one difference between them, that is, the semaphores count can exceed 1. almost all engineers can correctly understand that mutex is a binary sign that ensures that execution streams are mutually exclusive in the critical section of code, add protection to shared resources. however, when they were asked to further answer how to use the "computing method semaphore" approach, most engineers answered the question just like a textbook-semaphore is used to protect multiple similar resources.
By analogy, we can easily explain why "multiple resources" are flawed. if you think of a mutex as a key value owned by the operating system, we can easily compare a mutex to a bathroom key in a City Coffee Shop. if you want to use the bathroom but cannot find the key, you have to wait in a queue. similarly, mutex collaboratively serializes multiple tasks to achieve global resource sharing, and assigns a waiting queue to wait for tasks in a gradual manner.
However, this simple Resource Protection Protocol does not apply to two identical bathrooms. if we generalize a semaphore into a mutex to protect two or more identical resources, it is like a blue sub with two identical keys, you can use any one to open any bathroom door.
Therefore, semaphore itself cannot solve multiple problems with the same resource. guests in the coffee shop may only know the key, but they do not know which bathroom is available. if you try to use semaphore in this way, you will find that more state information is needed-they are usually shared resources protected by different mutex.
Correct use of semaphore is used to transmit signals from one task to another. mutex means obtaining and releasing resources. Every task using protected shared resources is in this order. in contrast, tasks that use semaphore usually do not send signals, but enter the waiting status, and cannot occur simultaneously.
For example, Task 1 may contain program code. When you press the "power" button, you can propose a special semaphore (such as sending signals or increments; task 2 is used to wake up the monitor based on the same semaphore. in this case, one task is the signal producer, and the other task is the signal consumer.

Here is an example to illustrate how to use mutex:
/* Task 1 */
Mutexwait (mutex_mens_room );
// Safely use shared resource
Mutexrelease (mutex_mens_room );

/* Task 2 */
Mutexwait (mutex_mens_room );
// Safely use shared resource
Mutexrelease (mutex_mens_room );

Correspondingly, you always use semaphore using the following methods:
/* Task 1-producer */
Sempost (sem_power_btn); // send the signal

/* Task 2-consumer */
Sempend (sem_power_btn); // wait for Signal

Importantly, semaphores can be used by interrupt service routine (ISR) interrupt service programs to send signals to tasks. sending a semaphore is a non-blocking RTOS behavior, and ISR security. this technology eliminates the possibility of errors caused by interruptions at the task level. sending signals from ISR is a more reliable design method for embedded software.