Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Understanding synchronisation internals: The mutex

Posted: 10 Nov 2015     Print Version  Bookmark and Share

Keywords:synchronisation primitives  embedded systems  mutex  semaphore  RTOS 

This leads to a concept known as inversion of control, which means that the scheduler is in charge of choosing when to suspend and resume your code as other tasks are quickly switched in and out. Using a variety of factors, such as task priority, the scheduler automatically decides what to run next. Mutexes and semaphores give us the ability to (a) conditionally suspend a task, and (b) influence how the scheduler chooses the next task to execute.

The problem of multi-threaded access
With inversion of control in mind, envision a program with three separate functions that run a simple printf statement to the console (or serial port) within a loop, as in figure 1.

Figure 1: With inversion of control in mind, envision a program with three separate functions that run a simple printf statement to the console (or serial port) within a loop.

Func1 outputs "hello 1", func2 outputs "hello 2" and func3 outputs "hello 3", over and over. Now imagine that the RTOS API is used to run each function in their own separate tasks as threads. Because there is no synchronisation among the three tasks, the console output will quickly become a jumbled mess—there's no way of controlling when the scheduler suspends and resumes each task. It might choose to suspend task 1 while it is in the middle of printing "hello 2" for task 2, etc.

But imagine if the three functions were to be re-written to share access to the console? One way to accomplish that would be to create a global variable as a flag, such as console_in_use does in figure 2.

Figure 2: One way to accomplish that would be to create a global variable as a flag, such as console_in_use does.

With a global flag, each task has the ability to check the flag and, if it's false, quickly set it to true, output the string, then reset it back to false before looping. This is an improvement, and it seems like it would work but, it isn't reliable and will still lead to jumbled output. The reason is because there's nothing to stop the scheduler from randomly suspending one task just after it has checked the flag, but before the flag gets to true. The test and set operation doesn't happen atomically. In such a situation, task 1 could correctly see that the flag is false and, just as it is ready to embark on the code path that would set the flag to true, it could be suspended by the scheduler and switch to task 2. At that point, task 2 examines the same flag, but because task 1 didn't get to finish assigning the flag to true, it also appears as false to task 2. Now, both tasks 1 and 2 will think the flag is false, so both will attempt to output their strings to the console, causing another jumbled mess.

The problem is that we need a trustworthy method of examining and setting the flag if it's false, regardless of how the scheduler chooses to perform its multi-tasking duties. There is a solution – the trusty mutex!

The mutex
Remember what we learned about inversion of control, in which the scheduler is in charge of executing tasks and not the other way around? If we strategically place a call to the mutex lock() operation at the right point in each function, we can safely coordinate, or protect, access to the shared resource (the printf function). All we have to do is replace the "if ( ! console_in_use )" block with paired calls to lock() and unlock() the mutex, respectively.

Figure 3 contains C code written for the Freescale MQX RTOS. In it, the new program coalesces the three print functions into a single print_task() routine. The main() function launches the RTOS and the main_task() function, which creates three separate instances of print_task() as threads, using the initial_data parameter to pass a unique pointer to each one.

Figure 3: One way to accomplish that would be to create a global variable as a flag, such as console_in_use does.


 First Page Previous Page 1 • 2 • 3 Next Page Last Page



Comment on "Understanding synchronisation intern..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top