[RT-Thread Reading Notes] Part 2 (3) Semaphores and Mutexes

我爱下载

[RT-Thread Reading Notes] Part 2 (3) Semaphores and Mutexes [Copy link]

 

Here we will learn about mutexes together, because mutexes are a special type of semaphore.

Semaphores are also very important content in RTOS, mainly realizing inter-thread communication mechanism, thread synchronization or mutual exclusive access to critical resources.

Semaphores are divided into binary semaphores and counting semaphores. The basic interface functions include semaphore creation, semaphore deletion, semaphore release, and semaphore acquisition.

It is worth noting here that the relationship between binary semaphores and mutexes is very similar, because they are very similar. However, binary semaphores can cause priority flipping problems during use, so mutexes came into being and effectively solved the priority flipping problem.

The following explains their differences. This content comes from the Internet, and I think it is written clearly.

Assume that we now have three tasks, task1, task2, and task3, with task1 having the highest task priority, and then decreasing in turn. We know that when two tasks are in the ready state at the same time during system scheduling, the system will give priority to the task with higher priority.

Okay, let's look at two cases:

l Priority inversion analysis (using semaphores)

---

In the example, we use the pend() function to indicate the acquisition of a semaphore and the post() function to indicate the release of a semaphore

[attach]412545 [/attach]

As shown in the figure above, the process is divided into the following steps

1) At the beginning, task3 starts running and obtains the semaphore first;

2) task1 starts running and tries to obtain the semaphore but fails and is blocked waiting for task3 to finish executing;

3) During the running of task3, task2 is triggered. Since its priority is higher than that of task3, task2 is run, wasting a lot of time;

4) Continue running task3 and release the semaphore after it finishes running;

5) task1 continues to run;

From here we can see that task1, which should have the highest priority, is the last to start running. This is the priority inversion phenomenon. This is obviously disadvantageous. For example, if a watchdog is installed, task1 will be triggered if it is not executed for a long time, causing the system to restart.

l Improved analysis (using mutex locks)

---

In the example, we use the lock() function to indicate the acquisition of a mutex lock, and the unlock() function to indicate the release of a mutex lock.

As shown in the figure above, the process is divided into the following steps

1) At the beginning, task3 starts running and obtains the mutex lock first

2) When task1 starts running, it tries to obtain the mutex lock but fails and is blocked waiting for task3 to finish executing. However, at this time, the priority of task3 is increased to make its priority the same as its own

3) During the running of task3, task2 is triggered. Since its priority is lower than that of task3 (it has been increased in step 2), task2 waits to run

4) Task3 continues to run and releases the mutex lock after running

5) Task1 continues to run

6) After task1 is executed, task2 is executed

So the process is the same as before, but the mutex lock has an extra step to raise the priority of task3 to the level of task1 to prevent task2 from disrupting the process and wasting a lot of time.

The comparison of the relationship between semaphores and mutexes comes from the Internet.

This content is created by EEWORLD forum user 我爱下载. If you need to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source

我爱下载

Some of the content comes from the Internet, but I think the explanation of semaphores and mutexes is very good, so I present it together as a study note.

southernsky

Careful