Mutex vs Semaphore

What are the differences between Mutex vs Semaphore? When to use mutex and when to use semaphore?

Concrete understanding of Operating System concepts is required to design/develop smart applications. Our objective is to educate  the reader on these concepts and learn from other expert geeks.

As per operating system terminology, mutex and semaphore are kernel resources that provide synchronization services (also called as synchronization primitives). Why do we need such synchronization primitives? Won’t be only one sufficient? To answer these questions, we need to understand few keywords. Please read the posts on atomicity and critical section. We will illustrate with examples to understand these concepts well, rather than following usual OS textual description.

The producer-consumer problem:

Note that the content is generalized explanation. Practical details vary with implementation.

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.

Using Mutex:

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 the entire buffer. The concept can be generalized using semaphore.

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.

General Questions:

1. Can a thread acquire more than one lock (Mutex)?

Yes, it is possible that a thread is in need of more than one resource, hence the locks. If any lock is not available the thread will wait (block) on the lock.

2. Can a mutex be locked more than once?

A mutex is a lock. Only one state (locked/unlocked) is associated with it. However, a recursive mutex can be locked more than once (POSIX complaint systems), in which a count is associated with it, yet retains only one state (locked/unlocked). The programmer must unlock the mutex as many number times as it was locked.

3. What happens if a non-recursive mutex is locked more than once.

Deadlock. If a thread which had already locked a mutex, tries to lock the mutex again, it will enter into the waiting list of that mutex, which results in deadlock. It is because no other thread can unlock the mutex. An operating system implementer can exercise care in identifying the owner of mutex and return if it is already locked by same thread to prevent deadlocks.

4. Are binary semaphore and mutex same?

No. We suggest to treat them separately, as it is explained signalling vs locking mechanisms. But a binary semaphore may experience the same critical issues (e.g. priority inversion) associated with mutex. We will cover these in later article.

A programmer can prefer mutex rather than creating a semaphore with count 1.

5. What is a mutex and critical section?

Some operating systems use the same word critical section in the API. Usually a mutex is costly operation due to protection protocols associated with it. At last, the objective of mutex is atomic access. There are other ways to achieve atomic access like disabling interrupts which can be much faster but ruins responsiveness. The alternate API makes use of disabling interrupts.

6. What are events?

The semantics of mutex, semaphore, event, critical section, etc… are same. All are synchronization primitives. Based on their cost in using them they are different. We should consult the OS documentation for exact details.

7. Can we acquire mutex/semaphore in an Interrupt Service Routine?

An ISR will run asynchronously in the context of current running thread. It is not recommended to query (blocking call) the availability of synchronization primitives in an ISR. The ISR are meant be short, the call to mutex/semaphore may block the current running thread. However, an ISR can signal a semaphore or unlock a mutex.

8. What we mean by “thread blocking on mutex/semaphore” when they are not available?

Every synchronization primitive has a waiting list associated with it. When the resource is not available, the requesting thread will be moved from the running list of processor to the waiting list of the synchronization primitive. When the resource is available, the higher priority thread on the waiting list gets the resource (more precisely, it depends on the scheduling policies).

9. Is it necessary that a thread must block always when resource is not available?

Not necessary. If the design is sure ‘what has to be done when resource is not available‘, the thread can take up that work (a different code branch). To support application requirements the OS provides non-blocking API.

For example POSIX pthread_mutex_trylock() API. When mutex is not available the function returns immediately whereas the API pthread_mutex_lock() blocks the thread till resource is available.


Also compare mutex/semaphores with Peterson’s algorithm and Dekker’s algorithm. A good reference is the Art of Concurrency book. Also explore reader locks and writer locks in Qt documentation.


Implement a program that prints a message “An instance is running” when executed more than once in the same session. For example, if we observe word application or Adobe reader in Windows, we can see only one instance in the task manager. How to implement it?

Article compiled by Venki. Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

Writing code in comment? Please use, generate link and share the link here.

  • Bill

    I disagree with your “disabling interrupts” statement. Disabling interrupts is only effective in single processor systems, and in modern processors it is a very expensive operation, even more than locking a mutex.

  • r00zster

    I feel like this is a lot of great information…sorry if this is rude, but there are a lot of grammar errors that make it a little hard to understand at some points, and require a few re-reads to fully comprehend.

    I mean I guess it’s not a big deal but it would certainly make it easier to understand the technical aspects. Not to take away from the content, which is great.

  • fateh_singh

    is another difference between mutex and thread is-

    –with “mutex” no other thread can unlock the lock
    in your thread
    –with “binary-semaphore” any other thread can unlock
    the lock in your thread

    • Anupam

      no…it mutex can sleep

  • DashDash

    Am I right here, as far as I understood the difference

    2 threads

    A B
    Wait(x) Release(x)
    //Critical section //Critical section
    Release(x) Wait(x)

    Here in case of mutex when A executes Wait(x) and goes into critical section and when B says Release(x) it will give error as A has locked it.

    But in case of semaphores when A is in critical section and B says Release(x) x will be incremented.

  • Vijay Should give you basic idea of semaphore and mutes. it explains the concept in simplified terms.

  • Aadishri

    I found this man-page of Semaphore at Yolinux useful

    Even Mutex is explained in detail

    /* check at for an example */
  • Titus

    Nice Post

    /* Paste your code here (You may delete these lines if not writing code) */
  • Titus

    Nice Post……

  • please refer this link for better clarification…
    and always remember that a semaphore is a generalized mutex..

  • Urvish

    Difference between Binary Semaphore and Mutex…
    (as per my understanding)

    Assume there are 3 processes, 2 producers and 1 consumer.
    Scheduling is like this. P1, P2, C, P1 ,P2, C,…..

    Now, lets say there is no stock.

    When it was turn of P1, it started producing. It got some stock ready and P1 will take mutex to add some stock. Just after it took mutex its time is over. Now key of LOCKED Mutex is with P1.

    Now it is turn of P2. It has some stock ready but it cannot add coz key is with P1. So, it will wait for lock to be opened by P1. Its time will be over just by waiting.

    Now, its C turn and it cannot consume anything as Key is with P1 and moreover, there is no stock.

    Next it will be P1’s turn and it will add stock and unlock. Then C can consume.

    Here, you can see that only owner (P1 here) can open lock. So the work is delayed.

    Now take case of Binary Semaphore. Here there is not like owner of semaphore.
    So in simple case, though P1 has locked it, as P2 has some stock ready, it will unlock and add some stock. So, in 1st cycle only, C will get it.

    //let me know if I am wrong somewhere.

  • autoAlgorithmist

    @Venki, I have got great confusion between binary semaphore & mutex It would be very helpful if you cite an example where binary semaphore fails & mutex performs the task?
    Thank you.

  • Naveen

    From General Question 2 – Does it mean recursive mutex and semaphores same ?
    Can you please give an example of recursive mutex ?

  • Vijay Ekkaladevi

    Though mutex & semaphores are used as synchronization primitives ,there is a big difference between them.
    In the case of mutex, only the thread that locked or acquired the mutex can unlock it.
    In the case of a semaphore, a thread waiting on a semaphore can be signaled by a different thread.
    Some operating system supports using mutex & semaphores between process. Typically usage is creating in shared memory.

  • will somebody provide solution for the exercise to help solve it..

    • Ganesh

      Here’s the idea…

      pthread_mutex_t lock;
      void *execute(void *arg)
       execl("some program...")
      int main(void)
       pthread_mutex_init(&lock, NULL);
       while(loop mulpltiple threads) 
         pthread_create(..,&execute ,...);
  • i like Finding Best Hashing Strategies and Hashing Functions.

  • Dumanshu

    @venki : i have heard that mutex is used for only threads whereas semaphores can be used for both processes and threads. is it true? because for different processes i don’t think its possible to have a shared mutex.

  • umesh

    Mutex and binary semaphore are same, the only diffrence might be of ownership. Rest is counting semaphore.

    • @umesh, If they are same why two different names? and why should they functionally different (ownership)? Can you cite an example, where binary semaphores and mutex can be used interchangeably?

      • umesh

        @venki, The binary semaphore can have two values 0 or 1, 0->process has to wait, 1->process can go ahead, the same applies to mutex too, the only case might be when locking a function having a series of function calls as all such functions also have to be locked in that case the binary semaphore fails and mutex is the right choice.

  • Tech_geek

    I still did not understand what is the difference between them. they are same. You can say that Mutex too is used for signaling like when one process will say ” I am done with these resources ” only after that other process can use those resources.

  • nice post again! fan of your blog.