Resource management using mutex

In this article we will discuss about resource management using mutex.

Resource management is an important and critical feature in RTOS based applications. In RTOS, we may have more than one tasks that share resources with each other such as peripherals, data, or external devices, etc.

For this purpose, FreeRTOS provides a mutex semaphore to share resources between tasks securely and without data corruption.

What is Mutex?

Mutex is special kind of binary semaphore which serves resource management between FreeRTOS tasks.

Resource management means it gives access of shared resources to two or more tasks serially. The word mutex is also known as mutual exclusion.?

Mutex means Mutual Exclusion. It makes sure that a single task has access to the resource at a particular time, thereby preventing several tasks from accessing a resource mutually. It acts as a flag whose aim is to grant access to a thread to a particular part of code at a time. The rest of the threads are locked out from acquiring that particular code/resource. This way the mutex ensures that no other threads corrupt the information and the execution for that code/resource is thread-safe. A mutex acts like a locking mechanism whereby it restricts multiple threads to simultaneously read and modify a common resource. A single thread is allowed to work on the resource and the rest wait for the key (mutex) to returned which may be used by another thread afterwards.

Why do we need to use mutex??

There are many cases in a multitasking system where more than one task uses a single resource to complete their execution. Therefore, a use of a single shared resource between multiple tasks can introduce multiple issues such as deadlocks, data corruption, priority inversion etc.

Let’s suppose, we use two tasks in our FreeRTOS application such as Task_A and Task_B. Both tasks write string operation on a LCD. Furthermore, the priority of Task_B is higher than the Task_A. That means Task_B can preempt Task_A.??

For example, if a task being its execution by accessing a shared resource, but will not be able to complete its execution before a high priority task takes the shared resource. If the task leaves the resource in an inconsistent state, then access to the same resource by any other task or interrupt could result in data corruption, or other similar issue.

Let’s take an example of above diagram where Task_B and Task_A both required access to an external peripheral LCD to display a string. For example, Task_A is in running state and begin printing a string text “ESP32 FreeRTOS Mutex” on the LCD. In the middle of Task_A execution, Task_B (high priority task)? preempts Task_A and TaskA has only printed “ESP32 FreeRTOS Mu” on the LCD. But Task_B has acquired the shared resource LCD. Task_B starts to execute and displays “LAB_1” on the LCD. After TaskB completes its execution, Task_A again starts its execution from the point where it was preempted by Task_B and prints “tex” on the LCD.??

Now final output on LCD will be “ESP32 FreeRTOS MuLAB_1tex”. But this is not what we wanted to display on LCD. Instead we wants to display “FreeRTOS Mutex LAB_1”. Hence, this is an issue of data corruption. We can resolve this issue by providing serialized access to shared resource (LCD) using FreeRTOS mutex semaphore.

How to use mutex to serialize shared resources access??

In the last example, we have seen an issue of data corruption where two tasks access the shared resource in an unexpected way. We will fix that issue with FreeRTOS mutex semaphore.

Let’s consider mutex as a token and only the process which has this token can acquire the shared resource regardless of what is priority of the task. For instance, the shared resource in this example is an LCD. Any task which wants to access LCD to write string, first it must access the token. In other words, it must become the token (mutex) holder. No other task will be able to access LCD, because it does not hold a token. Once a token holder completes its execution and finishes using the resource, it must release the token by giving it back to the resource. Only when the token has been returned can another task successfully take the token, and then safely access the same shared resource. A task is not permitted to access the shared resource unless it holds the mutex.?

ESP32 FreeRTOS Mutex Code

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include "freertos/FreeRTOS.h"

#include "freertos/task.h"

#include "freertos/semphr.h"

xSemaphoreHandle xMutex;

//shared resourse (printf) function

void write_message_console(char *message)

{

printf(message);

}

void temperature_task(void *params)

{

while (true)

{

printf("Inside temperature_task \n");

if (xSemaphoreTake(xMutex, portMAX_DELAY))

{

write_message_console("temperature is 35'c\n");

xSemaphoreGive(xMutex);

}

vTaskDelay(1000 / portTICK_PERIOD_MS);

}

}

void humidity_task(void *params)

{

while (true)

{

printf("Inside humidity_task\n");

if (xSemaphoreTake(xMutex, portMAX_DELAY))

{

write_message_console("humidity is 48% \n");

xSemaphoreGive(xMutex);

}

vTaskDelay(2000 / portTICK_PERIOD_MS);

}

}

void app_main(void)

{

xMutex = xSemaphoreCreateMutex();

xTaskCreate(&temperature_task, "temperature_task", 2048, NULL, 2, NULL);

xTaskCreate(&humidity_task, "humidity_task", 2048, NULL, 2, NULL);

}

IDE- ESP IDF

Board - ESP32 dev kit

Programming Language - C

Thanks for reading.