WHAT IS THE DIFFERENCE BETWEEN A MUTEX AND A SEMAPHORE?
Mutex vs Semaphores seems to be one of the most frequently asked questions in any interview dealing with Operating Systems like Linux, Windows, Symbian, Real Time Linux [RT Linux], PSOS, QNX etc
Even though the description for Mutex and Semaphore in OS context seems pretty simple, it is mostly in the implementation of these synchronizing mechanisms for any Operating System modules, that most of the system programmers end up in a big mess!
So here we are presenting you the simple definition and a real life example to help you understand the exact differences between a mutex and a semaphore.
So what is the background of mutex and semaphore that we are talking over here all the while when dealing with Operating Systems [OS]?
Well first, lets begin with some level of history of computers. During the early days of the computer programming, the entire computer system used to be pretty monotonous in nature in that, it could only do one task at a time and the next task could be submitted to the computer only after the currently executing task is completed.
However, as the computing industry evolved, the computer system got more and more powerful and the software used to run the machine - The OPERATING SYSTEM [OS] had slowly started managing multiple tasks execution in parallel. Even though when we say in parallel, a machine with one CPU and ALU [Arithmetic & Logic Unit] can only run one instruction at any given point of time.
However, since the speed of this instruction execution itself had increased, there were millions of instructions being executed per second.
As a result, the OS could assign instructions from multiple tasks [aka Applications like MS WORD, BROWSER etc] to be executed in a second, this creating an illusion to the end user as if all the tasks or Apps are running in parallel.
However, with these parallel application execution, there were certain resources like the video memory, printers etc that multiple Apps could be trying to access in parallel. In such a situation, the OS had to ensure that these critical resources are accessed in a synchronized way so as to avoid the applications from messing up each others' data. This could be achieved using several synchronization techniques among which, MUTEX and SEMAPHORES became significant.
Ok, So what is this mutex and semaphore that we are talking over here all the while when dealing with Operating Systems [OS]?
There are situations where in we can allow more than one applications, but not unlimited no. of them to access a critical resources. During this period of time, we would go for a Semaphore for synchronization mechanism which allows N no. of apps to gain access to the critical resource, before blocking the (N+1)th application. Thus, a semaphore has a count variable whose value decrements (as an App accesses the protected resource) from N until it reaches 0 and there after blocking any further access to the resource
On the other hand, there are also situations where in we cannot allow more than one app to access a critical resource, during which we go for Mutex. Mutex is nothing but a short form of MUTual EXclusion [MUTEX]
Thus, a mutex has a binary count which would allow an APP to access a resource when this count is 1 (and this results in count turning to 0) and then blocks any further apps from accessing the critical resource when its value turns to 0.
NOTE: All the while we spoke in terms of multiple apps. This was just to help understand the concept in a clear way. However, the same synchronization mechanism of semaphores and mutex applies even when same app tries to access a resource multiple time due to multi-threading or due to asynchronous interrupt routine too.
Err....NEED A REAL LIFE EXAMPLE TO UNDERSTAND THE CONCEPT OF MUTEX AND SEMAPHORE BETTER?
Now, if this rest room has 15 urinals, the manager keeps 15 keys at the entrance of the rest room for people to use. Everytime someone needs to get in, he will check for this key and if available, opens up the door and enjoy the liberation.
Now lets say there were 15 people who have entered the rest room using 15 keys kept outside. In that case, the 16th person who walks down to the rest room will be unable to open the lock and needs to wait until a person inside comes out with a key. This is a typical semaphore synchronization mechanism!
Mutex
On the other hand, lets assume that the rest room has only one urinal (A typical scenario in any budget pubs right!)
In this case, there can be only one key and whenever User1 has access to it, the next user - User2 needs to wait outside until User1 is out of the room. Typical Mutex case!!
Mutex vs Semaphores seems to be one of the most frequently asked questions in any interview dealing with Operating Systems like Linux, Windows, Symbian, Real Time Linux [RT Linux], PSOS, QNX etc
Even though the description for Mutex and Semaphore in OS context seems pretty simple, it is mostly in the implementation of these synchronizing mechanisms for any Operating System modules, that most of the system programmers end up in a big mess!
So here we are presenting you the simple definition and a real life example to help you understand the exact differences between a mutex and a semaphore.
So what is the background of mutex and semaphore that we are talking over here all the while when dealing with Operating Systems [OS]?
Well first, lets begin with some level of history of computers. During the early days of the computer programming, the entire computer system used to be pretty monotonous in nature in that, it could only do one task at a time and the next task could be submitted to the computer only after the currently executing task is completed.
However, as the computing industry evolved, the computer system got more and more powerful and the software used to run the machine - The OPERATING SYSTEM [OS] had slowly started managing multiple tasks execution in parallel. Even though when we say in parallel, a machine with one CPU and ALU [Arithmetic & Logic Unit] can only run one instruction at any given point of time.
However, since the speed of this instruction execution itself had increased, there were millions of instructions being executed per second.
As a result, the OS could assign instructions from multiple tasks [aka Applications like MS WORD, BROWSER etc] to be executed in a second, this creating an illusion to the end user as if all the tasks or Apps are running in parallel.
However, with these parallel application execution, there were certain resources like the video memory, printers etc that multiple Apps could be trying to access in parallel. In such a situation, the OS had to ensure that these critical resources are accessed in a synchronized way so as to avoid the applications from messing up each others' data. This could be achieved using several synchronization techniques among which, MUTEX and SEMAPHORES became significant.
Ok, So what is this mutex and semaphore that we are talking over here all the while when dealing with Operating Systems [OS]?
There are situations where in we can allow more than one applications, but not unlimited no. of them to access a critical resources. During this period of time, we would go for a Semaphore for synchronization mechanism which allows N no. of apps to gain access to the critical resource, before blocking the (N+1)th application. Thus, a semaphore has a count variable whose value decrements (as an App accesses the protected resource) from N until it reaches 0 and there after blocking any further access to the resource
On the other hand, there are also situations where in we cannot allow more than one app to access a critical resource, during which we go for Mutex. Mutex is nothing but a short form of MUTual EXclusion [MUTEX]
Thus, a mutex has a binary count which would allow an APP to access a resource when this count is 1 (and this results in count turning to 0) and then blocks any further apps from accessing the critical resource when its value turns to 0.
NOTE: All the while we spoke in terms of multiple apps. This was just to help understand the concept in a clear way. However, the same synchronization mechanism of semaphores and mutex applies even when same app tries to access a resource multiple time due to multi-threading or due to asynchronous interrupt routine too.
Err....NEED A REAL LIFE EXAMPLE TO UNDERSTAND THE CONCEPT OF MUTEX AND SEMAPHORE BETTER?
Imagine a urinal restroom whose door always gets locked when left free and need a key to open the door.
Semaphore:
Now, if this rest room has 15 urinals, the manager keeps 15 keys at the entrance of the rest room for people to use. Everytime someone needs to get in, he will check for this key and if available, opens up the door and enjoy the liberation. Now lets say there were 15 people who have entered the rest room using 15 keys kept outside. In that case, the 16th person who walks down to the rest room will be unable to open the lock and needs to wait until a person inside comes out with a key. This is a typical semaphore synchronization mechanism!
Mutex
In this case, there can be only one key and whenever User1 has access to it, the next user - User2 needs to wait outside until User1 is out of the room. Typical Mutex case!!
Post a Comment