The Challenge of Mutex in RTOS Tasks

Author | strongerHuang

WeChat Official Account | Embedded Column

When developing projects based on RTOS, it is common to encounter mutual exclusion situations, for example: multiple tasks need to use a single UART serial port for data transmission.

If mutex locks are not added, a higher priority task may preempt the serial port and send data, which could result in “garbled” data being sent.

Today, let’s discuss a common issue with mutex locks in RTOS development.

Readers who have studied RTOS should be familiar with mutual exclusion; a mutex lock is a type of “lock” designed to prevent tasks from preempting each other for a certain resource.

As mentioned above, if a single serial port is preempted by two tasks and no locks are applied, two tasks may send data simultaneously, resulting in “garbled” data;

However, if a mutex lock is applied, it will wait for other tasks to finish sending before continuing, ensuring data integrity (rather than garbled data);

Here is an example with three tasks and two mutex locks, as shown in the code below:

void task1(){  /*do something*/  OSMutex1_Pend();  // Lock mutex 1  /* Handle locked task */  OSMutex1_Post();  // Unlock mutex 1} void task2(){  /*do something*/  OSMutex1_Pend();  // Lock mutex 1  OSMutex2_Pend();  // Lock mutex 2  /* Handle locked task */  OSMutex2_Post();  // Unlock mutex 2  OSMutex1_Post();  // Unlock mutex 1} void task3(){  /*do something*/  OSMutex2_Pend();  // Lock mutex 2  /* Handle locked task */  OSMutex2_Post();  // Unlock mutex 2}

With this design, can you see the problem?

Experienced developers should catch it, but beginners might be puzzled.

In task 2, there are two locking and unlocking processes, and they are “interconnected”.

Assuming the priorities of task 1, task 2, and task 3 are: 1, 2, 3.

The priority order is: Task 1 > Task 2 > Task 3 (the smaller the number, the higher the task priority).

Assuming: Task 1 and Task 2 are in a waiting event state, i.e., they are blocked, while Task 3 is in a running state.

When Task 3 is “locking to handle tasks”, Task 2 preempts Task 3 (Task 2’s suspend time is up), at this point Task 3 is suspended, and Task 2 is in a running state;

If after Task 2 locks “Mutex 1”, Task 1 preempts Task 2, then Task 1 is in a running state;

At this point, do you see the problem?

When Task 1 executes “OSMutex1_Pend();“, it will wait for “mutex 1 to unlock”, and if no other method unlocks “mutex 1”, a “deadlock” situation can occur.

For example, improve the locking method of Task 2:

void task2(){  /*do something*/  OSMutex1_Pend();  // Lock mutex 1  /* do something */  OSMutex1_Post();  // Unlock mutex 1  OSMutex2_Pend();  // Lock mutex 2  /* do something */  OSMutex2_Post();  // Unlock mutex 2}

Or improve the locking method of lower priority Task 3:

void task3(){  /*do something*/  OSMutex1_Pend();  // Lock mutex 1  OSMutex2_Pend();  // Lock mutex 2  /* Handle locked task */  OSMutex2_Post();  // Unlock mutex 2  OSMutex1_Post();  // Unlock mutex 1}

Click “Read Original” to see more shares.