摘自：

Mastering the FreeRTOS 7.3 Mutexes (and Binary Semaphores)

Priority Inversion

This Figure demonstrates one of the potential pitfalls of using a mutex to provide mutual

exclusion. The sequence of execution depicted shows the higher priority Task 2 having to wait

for the lower priority Task 1 to give up control of the mutex. A higher priority task being

delayed by a lower priority task in this manner is called ‘priority inversion’. This undesirable

behavior would be exaggerated further if a medium priority task started to execute while the

high priority task was waiting for the semaphore—the result would be a high priority task

waiting for a low priority task—without the low priority task even being able to execute. This

worst case scenario is shown in Figure below:

Figure.  A worst case priority inversion scenario

Priority inversion can be a significant problem, but in small embedded systems it can often be

avoided at system design time, by considering how resources are accessed.

Priority Inheritance

OS mutexes and binary semaphores are very similar—the difference being that

mutexes include a basic ‘priority inheritance’ mechanism, whereas binary semaphores do not.

Priority inheritance is a scheme that minimizes the negative effects of priority inversion. It

does not ‘fix’ priority inversion, but merely lessens its impact by ensuring that the inversion is

always time bounded. However, priority inheritance complicates system timing analysis, and it

is not good practice to rely on it for correct system operation.

Priority inheritance works by temporarily raising the priority of the mutex holder to the priority of

the highest priority task that is attempting to obtain the same mutex. The low priority task that

holds the mutex ‘inherits’ the priority of the task waiting for the mutex. This is demonstrated by

Figure below. The priority of the mutex holder is reset automatically to its original value when it

gives the mutex back.

Figure. Priority inheritance minimizing the effect of priority inversion

As just seen, priority inheritance functionality effects the priority of tasks that are using the

mutex. For that reason, mutexes must not be used from an interrupt service routines.

Deadlock (or Deadly Embrace)

‘Deadlock’ is another potential pitfall of using mutexes for mutual exclusion. Deadlock is

sometimes also known by the more dramatic name ‘deadly embrace’.

Deadlock occurs when two tasks cannot proceed because they are both waiting for a resource

that is held by the other. Consider the following scenario where Task A and Task B both need

to acquire mutex X and mutex Y in order to perform an action:

1. Task A executes and successfully takes mutex X.

2. Task A is pre-empted by Task B.

3. Task B successfully takes mutex Y before attempting to also take mutex X—but mutex

X is held by Task A so is not available to Task B. Task B opts to enter the Blocked

state to wait for mutex X to be released.

4. Task A continues executing. It attempts to take mutex Y—but mutex Y is held by Task

B, so is not available to Task A. Task A opts to enter the Blocked state to wait for

mutex Y to be released.

At the end of this scenario, Task A is waiting for a mutex held by Task B, and Task B is waiting for a mutex held by Task A. Deadlock has occurred because neither task can proceed. 最简单的死锁场景：自死锁。一个任务试图去获得一个自己已经持有的锁。 As with priority inversion, the best method of avoiding deadlock is to consider its potential at design time, and design the system to ensure that deadlock cannot occur. In particular, and as previously stated in this book, it is normally bad practice for a task to wait indefinitely (without a time out) to obtain a mutex. Instead, use a time out that is a little longer than the maximum time it is expected to have to wait for the mutex—then failure to obtain the mutex within that time will be a symptom of a design error, which might be a deadlock. In practice, deadlock is not a big problem in small embedded systems, because the system designers can have a good understanding of the entire application, and so can identify and remove the areas where it could occur.