Understanding Mutex Issues in RTOS Development

Follow+Star Public Number, don’t miss the wonderful content

Author | strongerHuang

Public Account | Embedded Column

When developing projects based on RTOS, it is common to encounter mutex situations, such as: multiple tasks needing to use a single UART serial port to send data.

If mutex locks are not added, higher priority tasks may preempt the serial port and send data, which could result in sending garbled data.

Today, I will discuss a common issue with mutex locks in RTOS development.

What is a Mutex?

Readers who have studied RTOS should be familiar with mutexes; a mutex is a type of “lock” designed to prevent tasks from preempting each other when accessing a shared resource.

As mentioned above, if two tasks preempt a single serial port without a lock, they may send data simultaneously, resulting in garbled output;

However, if a mutex lock is added, the task will wait until other tasks have finished sending before continuing, ensuring data integrity (instead of garbled data);

Embedded Column

Example of Mutex

Here’s an example with three tasks and two mutexes, the code is as follows:

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

With this design, do you see the problem?

Experienced developers should notice, while beginners may be confused.

In task 2, there are two locking and unlocking operations, and they are “interlinked”.

Mutex Issues

Suppose tasks 1, 2, and 3 have priorities of:1, 2, 3.

The priority order is: Task 1 > Task 2 > Task 3 (the lower 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 running.

When task 3 is “locking to handle tasks”, task 2 preempts task 3 (task 2’s wait time is up), at this point task 3 is suspended, and task 2 is running;

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

At this point, do you see the problem?

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

Here’s an image to help you understand what a deadlock is:

Solution

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 tasks*/  OSMutex2_Post();  //Unlock mutex 2  OSMutex1_Post();  //Unlock mutex 1}

The issue arises when a task holds a lock on a critical resource and attempts to acquire another lock without releasing the first; this is a scenario that requires careful attention, and the success of your design relies on whether you thoroughly understand the previous issues.

Ultimately, such issues require users to avoid them during the design phase; a system cannot be all-encompassing, and correct design is paramount.

———— END ————

Understanding Mutex Issues in RTOS Development

● Column “Embedded Tools”

● Column “Embedded Development”

● Column “Keil Tutorial”

● Selected Tutorials from Embedded Column

Follow the public accountReply “Join Group” to join the technical exchange group, reply “1024” to see more content.

Click “Read Original” to see more shares.

Leave a Comment Cancel reply