Whenever we listen to the term “mutex lock” then some questions come to our mind like what is mutex lock and the use of mutex lock in programming.  This blog will explain the mutex lock, including priority inversion, priority inheritance, and priority ceiling protocols.

The following topic we will cover in this article:

• What is mutex?
• How does mutex work?
• When and where we should use mutex?
• Advantages and Disadvantages of mutex?

What is mutex?

A Mutex is a mutually exclusive object which protects the shared resources from simultaneous access by multiple threads or processes. It acts as a gatekeeper to a section of code allowing one thread in and blocking access to all others. This ensures that the code being controlled will only be hit by a single thread at a time.

Mutex work on the locking mechanism, the thread which locks the mutex can only unlock it. So you must release the mutex after the use of share resources otherwise it causes serious issues.

When and where we should use mutex?

Let’s understand the scenario where a mutex is required to use. So suppose you are working on a multi-threaded application. In this application, different threads share a common resource,  such as global memory and peripheral devices. By global memory, I mean a piece of data whether it is a global variable or a global data structure. Also, global functions which are not thread-safe can be considered global memory.

The main issue arises when the actual end result depends on the sequence of execution of the threads but the execution sequence is not intended by programmers. This type of scenario is called a race condition. Its effect is serious, let’s understand an example of race condition.

See the below image, in which you can see the first screen is displaying the name in expected order because no race condition is detected but for the second screen name is not displaying in proper order due to race condition.

It is the reason we must avoid access to the shared resource at the same time, and also we need a construct to ensure that only one thread uses the shared resource at a time. This concept is called “mutual exclusion“, and is a way to ensure that only one thread is allowed inside that area, using that resource.

We can achieve mutual exclusion by mutual exclusion mechanisms like Semaphores, Readers–writer locks, scheduler locks, critical section,s, or mutex ..etc.

But here we will only discuss the mutex. In the above case screen resources (shared resources) are accessed by two threads, mutex allows only one thread at a time to access the screen resources.

//dummy code

lock(); //locks
…..
Critical Section
…..
unlock(); //unlocks

It ensures that the code in the critical section (which has shared resources) being controlled will only be used by a single thread at a time. 

How does a Mutex work?

Let’s first understand the working of mutex by considering newbies, with a real-life example. Suppose there is a switch in the phone booth and if someone wants to talk on the phone, they have to press the switch till the time they want to talk. If the switch is pressed, No other person is allowed to enter the phone booth.

Let’s assume there is another person who wants to talk on the phone. The first person who pressed the switch is only allowed to use the phone. He has to press the switch as long as he uses the phone, otherwise, someone else will press the switch, throw him out and use the phone. When the person finishes his call, releases the switch, and comes out of the booth, the next person to get the press the switch will be allowed to use the phone.

Here,

Switch           ->   Mutex

Phone            ->   Shared Resource

Pressing Switch  ->   Lock

Releasing Switch ->   Unlock

Person           ->   Thread (Task)

Similar to the switch “mutex” is used for protecting the shared resources. It avoids the conflicts caused by the simultaneous uses of a resource at a time. The task (thread) that uses the shared resource first claims it by calling the mutex lock() API function ( Like pressing the switch ). If the shared resource is available, the execution of the program for the task will continue (Like, a phone call start).

Note: The task that “owns” the mutex at a given time, can only perform the ‘unlock’ operation on the mutex.

But the shared resource is blocked for the other tasks and they are not allowed to use the resource ( like the other person who wants to use the phone while someone is talking). If any other task now tries to use the shared resource while it is in use by the first task, the task goes in the suspended state until the first task releases the resource ( Like the first person finishes his call and releases the switch ).

Note: The waiting task will immediately become the new “owner” of the mutex if the ‘unlock’ operation is done. But if several tasks are waiting for the mutex, the scheduler decides which would be the new single “owner” on the basis of defined criteria.

I believe now you are able to understand how mutex protects the shared resources using the locking mechanism.

Recommended Post

• Mastering in Rtos.
• Introduction to Real-Time Operating System (RTOS).
• Rtos Task States.
• Interview Questions on RTOS.
• Can protocol interview Questions.
• HDLC Protocol introduction.
• 100 C interview Questions.
• Embedded system interview Questions with Answers
• I2C interview Questions
• Interview questions on bitwise operators in C