Mutex Issues Between RTOS Tasks

If mutex locks are not used, a higher priority task may preempt the UART and send data, potentially resulting in “garbled” data being sent.

Today, we will discuss a common problem regarding mutex locks in RTOS development.

As mentioned earlier, if a UART is preempted by two tasks without locking, it can lead to interleaved data being sent, resulting in “garbled” output.

However, if a mutex lock is applied, the task will wait until other tasks have completed their sending before proceeding, ensuring the integrity of the data (rather than garbled output).

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 tasks */  OSMutex1_Post();  // Unlock mutex 1}
void task2(){  /*do something*/   OSMutex1_Pend();  // Lock mutex 1  OSMutex2_Pend();  // Lock mutex 2  /* Handle tasks */  OSMutex2_Post();  // Unlock mutex 2  OSMutex1_Post();  // Unlock mutex 1}
void task3(){  /*do something*/  OSMutex2_Pend();  // Lock mutex 2  /* Handle tasks */  OSMutex2_Post();  // Unlock mutex 2}

Experienced developers might notice it, while beginners may be puzzled.

In task 2, there are two lock/unlock operations that are “interlinked”.

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

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

When Task 3 is “handling the lock”, Task 2 preempts Task 3 (Task 2’s waiting time is up), causing Task 3 to suspend, and Task 2 is now running;

If Task 2 locks mutex 1 and then Task 1 preempts Task 2, at this point, Task 1 is running;

Do you see the issue now?

Task 1 executing “OSMutex1_Pend();” will wait for the “mutex 1 unlock”, and if no other means unlocks “mutex 1”, a “deadlock” situation may occur.

For example, we can improve the locking method for 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}

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

The problem arises when a task acquires a lock for a critical resource and tries to acquire another lock for another critical resource without releasing the first lock; this should be approached with caution. The success of the design hinges on whether you thoroughly understand the previous issues.

Ultimately, such issues require users to avoid them during the design phase; no system can be perfect; correct design is paramount.

END