In our previous tutorials, we have seen Semaphore. Now we are going to see FreeRTOS Mutex Tutorial using LPC2148. let’s start.
- 1 Suggest To Read
- 2 FreeRTOS Mutex Tutorial using LPC2148
- 3 Introduction
- 4 Mutex vs Semaphore
- 5 APIs Used
- 6 Code
- 7 Output
Suggest To Read
FreeRTOS Mutex Tutorial using LPC2148
Before we starting this tutorial we should know about the semaphore. If you go through the RTOS Basics two parts you can go ahead.For others I will give you the small introduction about semaphore.
A semaphore (sometimes called a semaphore token) is a kernel object that one or more threads of execution can acquire or release for the purposes of synchronization or mutual exclusion. This is useful for when two or more task accessing same resource. A binary semaphore used for synchronization does not need to be ‘given’ back after it has been successfully ‘taken’ (obtained).
A kernel can support many different types of semaphores, including
- counting, and
- mutual‐exclusion (mutex) semaphores.
- Similar to mutex
- Can have a value 1 or 0
- Whenever a task asks for semaphore, the OS checks if the semaphore’s value is 1
- If so, the call succeeds and the value is set to 0
- Else, the task is blocked
Binary semaphores are treated as global resources,
- They are shared among all tasks that need them.
- Making the semaphore a global resource allows any task to release it, even if the task did not initially acquire it?
- Semaphores with an initial value greater than 1
- can give multiple tasks simultaneous access to a shared resource, unlike a mutex
- Priority inheritance, therefore, cannot be implemented
Are powerful tools for synchronizing access to shared resources. A mutual exclusion (mutex) semaphore is a special binary semaphore that supports
- recursive access,
- task deletion safety, and
- one or more protocols for avoiding problems inherent to mutual exclusion.
A task that obtains a mutex that is used for mutual exclusion must always give the mutex back – otherwise no other task will ever be able to obtain the same mutex. But in semaphore any task can take semaphore and any task can give semaphore.
Problems that may arise with mutexes
- priority Inversion
Binary semaphores and mutexes are very similar, but do have some subtle differences. Mutexes include a priority inheritance mechanism, binary semaphores do not. This makes binary semaphores the better choice for implementing synchronization (between tasks or between tasks and an interrupt), and mutexes the better choice for implementing simple mutual exclusion.
Mutex vs Semaphore
Consider the standard producer-consumer problem. Assume, we have a buffer of 4096 byte length. A producer thread collects the data and writes it to the buffer. A consumer thread processes the collected data from the buffer. Objective is, both the threads should not run at the same time.
- A mutex provides mutual exclusion, either producer or consumer can have the key (mutex) and proceed with their work. As long as the buffer is filled by producer, the consumer needs to wait, and vice versa.
- At any point of time, only one thread can work with theentire The concept can be generalized using semaphore.
A semaphore is a generalized mutex. In lieu of single buffer, we can split the 4 KB buffer into four 1 KB buffers (identical resources). A semaphore can be associated with these four buffers. The consumer and producer can work on different buffers at the same time.
- There is an ambiguity between binary semaphore and mutex. We might have come across that a mutex is binary semaphore. But they are not! The purpose of mutex and semaphore are different. May be, due to similarity in their implementation a mutex would be referred as binary semaphore.
- Strictly speaking, a mutex is locking mechanism used to synchronize access to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there is ownership associated with mutex, and only the owner can release the lock (mutex).
- Semaphore is signaling mechanism (“I am done, you can carry on” kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend calls you, an interrupt is triggered upon which an interrupt service routine (ISR) signals the call processing task to wakeup.
- xSemaphoreGive ()
Here we have already know the last two APIs. Because we were already discussed in our previous tutorials.
Creates a mutex type semaphore, and returns a handle by which the mutex can be
referenced. Each mutex type semaphore requires a small amount of RAM that is used to hold the semaphore’s state. If a mutex is created using xSemaphoreCreateMutex() then the required RAM is automatically allocated from the FreeRTOS heap. If a mutex is created using xSemaphoreCreateMutexStatic() then the RAM is provided by the application writer, which requires an additional parameter, but allows the RAM to be statically allocated at compile time.
SemaphoreHandle_t xSemaphoreCreateMutex( void );
for Mutex you should add below line in the FreeRTOSConfig.h
#define configUSE_MUTEXES 1
- NULL Returned if the semaphore cannot be created because there is insufficient
heap memory available for FreeRTOS to allocate the semaphore data structures.
- Any other value The semaphore was created successfully. The returned value is a handle
by which the created semaphore can be referenced.
Return the handle of the task that holds the mutex specified by the function parameter, if any
TaskHandle_t xSemaphoreGetMutexHolder( SemaphoreHandle_t xMutex );
- xMutex : The handle of the mutex being queried.
- The semaphore specified by the xMutex parameter is not a mutex type semaphore, or
- The semaphore is available, and not held by any task.
Any other value The handle of the task that holds the semaphore specified by the xMutex parameter.
xSemaphoreGetMutexHolder() can be used reliably to determine if the calling task is the mutex holder, but cannot be used reliably if the mutex is held by any task other than the calling task. This is because the mutex holder might change between the calling task calling the function, and the calling task testing the function’s return value.
configUSE_MUTEXES and INCLUDE_xSemaphoreGetMutexHolder must both be set to 1 in FreeRTOSConfig.h for xSemaphoreGetMutexHolder() to be available.
This program contains two tasks. Initially task 1 takes the mutex and prints the data. Then that task release the mutex. Then task2 takes the mutex and prints data. Finally task2 release the data. So here unlike semaphore, who acquire the mutex they only need to release. If you want to download full project, please visit Here.
void task1(void *p);
void task2(void *p);
xMutex=xSemaphoreCreateMutex(); //xMutex will be storing NULL when Mutex not created
void task1(void *p)
xSemaphoreGive( xMutex );
void task2(void *p)