Difference between binary semaphore and mutex

Question

Is there any difference between a binary semaphore and mutex or are they essentially the same?

Solution 1

They are NOT the same thing. They are used for different purposes!
While both types of semaphores have a full/empty state and use the same API, their usage is very different.

Mutual Exclusion Semaphores
Mutual Exclusion semaphores are used to protect shared resources (data structure, file, etc..).

A Mutex semaphore is "owned" by the task that takes it. If Task B attempts to semGive a mutex currently held by Task A, Task B's call will return an error and fail.

Mutexes always use the following sequence:

  - SemTake
  - Critical Section
  - SemGive

Here is a simple example:

  Thread A                     Thread B
   Take Mutex
     access data
     ...                        Take Mutex  <== Will block
     ...
   Give Mutex                     access data  <== Unblocks
                                  ...
                                Give Mutex

Binary Semaphore
Binary Semaphore address a totally different question:

• Task B is pended waiting for something to happen (a sensor being tripped for example).
• Sensor Trips and an Interrupt Service Routine runs. It needs to notify a task of the trip.
• Task B should run and take appropriate actions for the sensor trip. Then go back to waiting.

   Task A                      Task B
   ...                         Take BinSemaphore   <== wait for something
   Do Something Noteworthy
   Give BinSemaphore           do something    <== unblocks

Note that with a binary semaphore, it is OK for B to take the semaphore and A to give it.
Again, a binary semaphore is NOT protecting a resource from access. The act of Giving and Taking a semaphore are fundamentally decoupled.
It typically makes little sense for the same task to so a give and a take on the same binary semaphore.

Solution 2

• A mutex can be released only by the thread that had acquired it.
  
• A binary semaphore can be signaled by any thread (or process).

so semaphores are more suitable for some synchronization problems like producer-consumer.

On Windows, binary semaphores are more like event objects than mutexes.

Solution 3

The Toilet example is an enjoyable analogy:

Mutex:

Is a key to a toilet. One person can have the key - occupy the toilet - at the time. When finished, the person gives (frees) the key to the next person in the queue.

Officially: "Mutexes are typically used to serialise access to a section of re-entrant code that cannot be executed concurrently by more than one thread. A mutex object only allows one thread into a controlled section, forcing other threads which attempt to gain access to that section to wait until the first thread has exited from that section." Ref: Symbian Developer Library

(A mutex is really a semaphore with value 1.)

Semaphore:

Is the number of free identical toilet keys. Example, say we have four toilets with identical locks and keys. The semaphore count - the count of keys - is set to 4 at beginning (all four toilets are free), then the count value is decremented as people are coming in. If all toilets are full, ie. there are no free keys left, the semaphore count is 0. Now, when eq. one person leaves the toilet, semaphore is increased to 1 (one free key), and given to the next person in the queue.

Officially: "A semaphore restricts the number of simultaneous users of a shared resource up to a maximum number. Threads can request access to the resource (decrementing the semaphore), and can signal that they have finished using the resource (incrementing the semaphore)." Ref: Symbian Developer Library

Solution 4

Nice articles on the topic:

• MUTEX VS. SEMAPHORES – PART 1: SEMAPHORES
• MUTEX VS. SEMAPHORES – PART 2: THE MUTEX
• MUTEX VS. SEMAPHORES – PART 3 (FINAL PART): MUTUAL EXCLUSION PROBLEMS

From part 2:

The mutex is similar to the principles of the binary semaphore with one significant difference: the principle of ownership. Ownership is the simple concept that when a task locks (acquires) a mutex only it can unlock (release) it. If a task tries to unlock a mutex it hasn’t locked (thus doesn’t own) then an error condition is encountered and, most importantly, the mutex is not unlocked. If the mutual exclusion object doesn't have ownership then, irrelevant of what it is called, it is not a mutex.

Solution 5

Since none of the above answer clears the confusion, here is one which cleared my confusion.

Strictly speaking, a mutex is a 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 will be 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 called you, an interrupt will be triggered upon which an interrupt service routine (ISR) will signal the call processing task to wakeup.

Source: http://www.geeksforgeeks.org/mutex-vs-semaphore/

View more solutions

Comments

[Michael Foukarakis]

They're semantically the same, but in practice you will notice weird differences (especially on Windows).

[Philipp]

@Michael Foukarakis: What are the weird differences?

[Michael Foukarakis]

I suppose weird wasn't the correct expression. A mutex also supports ownership and sometimes reentry. This is the case in Windows. In addition, semaphores in Windows are implemented on top of Event objects, however, I'm unsure of the practical implications of this.

[Karthik Balaguru]

Similar discussion in stackoverflow.com/questions/4039899/…

[philipxy]

They are the same thing. Eg Hoare 1972 Monitors: An Operating System Structuring Concept "Obviously, we shall require for each monitor a Boolean semaphore "rnutex" to ensure that the bodies of the local procedures exclude each other. The semaphore is initialized to 1; a P(mutex) must be executed on entry to each local procedure, and a V(mutex) must usually be executed on exit from it." Various systems, languages, libraries etc use generic terms with specialized meaning. A word means what people agree it means. (If they can manage it.) Define your terms, and have others define theirs.

[Admin]

this video is worth thousend words : youtube.com/watch?v=DvF3AsTglUU

[Volkan Güven]

Btw, you should accept an answer :) So many good answers are down there waiting to be accepted tho I would say @Benoit answer is quite worthy.

[Mooncrater]

@philipxy Nicely hid 'rn' in place of 'm'.

[philipxy]

@Mooncrater Wow. Good eye. I expect its due to OCR. (Yes, it is.)

[Ayyappa Gollu]

watch this lecture video from MIT 6004. youtube.com/watch?v=TVkQ1VeRKt4

[Amaresh Kumar]

i see lot of answers copied and pasted from gauss.ececs.uc.edu/Courses/c3003/extra/…

[einpoklum]

@MichaelFoukarakis: Please remove your comment - binary semaphores are really not the same as mutex'es.

[hrishi007]

If anyone prefer video watch this (youtu.be/8wcuLCvMmF8) video you will get clear understanding

[Jason]

I don't think it is common practice for a mutex to be implemented with spinlocks. On a Uni-proc machine this would be absolutely terrible for performance.

[ConcernedOfTunbridgeWells]

Normally you would only use spinlocks on multi-processor systems.

[Roman Nikitchenko]

... but this is regarding mutex vs counting semaphore. The question was asked about binary.

[Anna B]

The kind of mutex you are talking about are called "recursive mutex" and should be avoided since they are slow and tend to promote bad design: (see David Butenhof: zaval.org/resources/library/butenhof1.html)

[Casey Barker]

Agreed. On this particular OS, I use the mutex service where I want to make it clear that the code is for "mutual exclusion" and not reference counting, but I don't use the recursive feature for fear of ugly unwinding. Still, in the context of the question, this is an important difference between a "mutex" and "binary semaphore."

[Dan]

Good answer. In #2 you are describing a recursive mutex -- not all mutexes are necessarily recursive. E.g., cs.wustl.edu/~schmidt/ACE.FAQ.html#Q14

[Ofer]

Thanks for the link, the explanations there are excellent. The link has changed: feabhas.com/blog/2009/09/… (Use < Prev and Next > to navigate to the other two articles.

[kgriffs]

Note - the lack of ownership also prevents the operating system from working around priority inversion. For this reason, I generally use condition variables as opposed to semaphores for producer/consumer architectures.

[Ajeet Ganga]

While what is said by david is correct, but it is NOT the answer to the question asked. Mladen Jankovic answer is the answer to the question asked, where point is made to differentiate "binary-semaphore" vs "mutex".

[Ajeet Ganga]

+1 foe excellent article links. The best article explaining semaphore and mutex with "what-it-is" and "what-it-does" computing.llnl.gov/tutorials/pthreads I had used this article as my behind the scene reference, which technically does explain everything about mutex/conditionals and other constructs built on their top like semaphore/barrier/reader-writer, but nowhere explicit and concise about problems faced with constructs. In short it is reference. :)

[curiousguy]

In which specific cases is fairness guaranteed for semaphores but not for mutexes?

[curiousguy]

i) Wrong. ii) Source? iii) It depends.

[jilles]

POSIX has specific requirements which thread should be awakened by sem_post() for SCHED_FIFO and SCHED_RR (both of these are not default): the highest priority thread, and if there are multiple with the same priority, the thread that has been waiting the longest. OpenSolaris follows this FIFO rule to some degree even for normal scheduling. For glibc and FreeBSD, unlocking a simple mutex (i.e. not priority protect or priority inherit) and posting a semaphore are basically the same, marking the object as unlocked and then, if there may be waiting threads, calling the kernel to wake one.

[Pacerier]

Isn't a mutex better than a binary semaphore then? Since it doesn't make sense if someone releases a lock which he doesn't actually hold.

[Benoit]

They have different purposes. Mutex is for exclusive access to a resource. A Binary semaphore should be used for Synchronization (i.e. "Hey Someone! This occurred!"). The Binary "giver" simply notifies whoever the "taker" that what they were waiting for happened.

[Benoit]

@Pacerier You are confusing the purpose. A mutex is intended protect a critical region. You are correct it doesn't make sense to use a Binary Semaphore. I'll update the answer to explain the purpose of each.

[Raulp]

what is ownership?You mean the context which acquires mutex can only un-aquire it.??

[daisy]

Mutex can be released only by thread that had acquired it -- I just tried with a simple pthread_mutex based program, a thread can unlock mutex locked in main thread

[amit kumar]

@warl0ck As per the man page of pthread_mutex_lock linux.die.net/man/3/pthread_mutex_lock : "If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided....If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned."

[NeonGlow]

Unfortunately, this incorrect answer has more votes than the best answer by @Benoit

[nik7]

A semaphore restricts the number of simultaneous users of a shared resource up to a maximum number. This is it. Thanks.

[FrostNovaZzz]

@warl0ck Please see stackoverflow.com/a/5492499/385064 'Pthreads has 3 different kinds of mutexes: Fast mutex, recursive mutex, and error checking mutex. You used a fast mutex which, for performance reasons, will not check for this error. If you use the error checking mutex on Linux you will find you get the results you expect.'

[abhi]

@Benoit So Can we say that Mutex are Used for atomicity and Binary Semaphore for Ordering perspective since Task B will be waiting for Task A to signal the release of lock inherently making sure of ordering of operations on a data strurcture?

[Benoit]

@abhi That's a good way to look at it for the Mutex. However, depending on the OS, you can have more than one recipient waiting on a binary semaphore. In that case, only one of the client will get the binary sem. The other(s) would wait for a subsequent one. Is the order of receiving known or guaranteed? Depends on the OS.

[Hemanth]

This answer is misleading.Should have compared only with Binary Semaphore.

[Harsh]

@Benoit So if binary Semaphore is used for synchronization, then shouldn't Counting Semaphore be used in a similar sense? Could you pls tell how counting semaphore be used for synchronization among N tasks?

[antred]

So would it be fair to say that boost::condition_variable (or std::condition_variable, since C++11) is really a semaphore?

[Technophile]

This also demonstrates a problem with using a counting semaphore to protect a shared resource: if the keys are indeed identical, and a toilet is unlocked using a key, and there is no other mechanism to distribute cubicle usage, then: (1) the first user unlocks, enters and starts to use the first cubicle. (2) the next user unlocks, enters and starts to use the first cubicle...

[Jacob Ritchie]

I don't see the problem - a binary semaphore is simply a counting semaphore where the max count is 1. The analogy still applies perfectly well. The difference is that the semaphore maintains a count.

[Donbhupi]

@JacobRitchie the problem is with the statement that says "A mutex is really a semaphore with value 1" but that is not the case. ThreadA and only ThreadA can increment (and hence release) the mutex that it decremented whereas ThreadB can increment the binSemaphore decremented by ThreadA, which also happens to be the answer to the question in question.

[achoora]

In our code we have used mutex also for synchronization purposes.The Thread which locks the mutex again tried to lock the mutex.Then it goes to blocked state.What we have seen is that we are able to unlock this from another thread .Thus achieving synchronization between the two.We are using posix standard only .So the major difference sited between mutex and binary semaphore seems vague.

[seokhoonlee]

Resources to supplement the answer: binary mutex

[KRoy]

@Benoit I noticed that the difference are in two way intent and behavior. These two words are also important in design patterns. I also noticed that the mutexes are more like state-pattern where the state changes by the algorithm that is selected by the state. And binary-semaphores are like strategy-pattern where the state can be changed by external algorithm.

[KRoy]

@achoora I agree that it is wrong to specialize semaphore for synchronization. Actually all the mutex,binary-semaphore,barrier,pipelines are different patterns for synchronization. In design perspective, mutex are more like state-pattern where the algorithm that is selected by the state can change the state. The binary-semaphore are more like strategy pattern where the external algorithm can change the state and eventually the algorithm/strategy selected to run.

[G. Bach]

The little book of semaphores is a valuable read about these issues.

[Myanju]

"can be signaled by a different thread" what is it mean give an example.

[IInspectable]

In other words: A binary semaphore is identical to a mutex. Downvoted for presenting the information of a one-liner in several paragraphs. And not even addressing the question being asked.

[algrid]

But from this explanation follows that semantically at some level it’s absolutely the same thing. The typical scenario of usage is different, some technical details of implementation may differ like possibility to unloc/signal from another thread. But otherwise it’s the same - program just waits for something to continue execution and another part of the program can make that “something“ happen.

[Kindred]

more easily understood than the other answers.

[Brain2000]

So you're saying if I screw up a mutex I might end up in a bathroom crossing streams with some stranger!?

[Admin]

Can we agree on the fact that what is nowadays called a binary semaphore shouldn't be called a binary semaphore, as it is used as a signalling mechanism?

[Toan Tran]

@Benoit But Singal condition of mutex could do the same thing with Semaphore right?

[Toan Tran]

@Maladen But mutex has condition come along with it, the condition signal could do the same thing with Semaphore, right?

[user1606191]

Can we say from this explanation that mutex can be used to give atomicity to the critical section code whereas a binary semaphore can be used when the critical section requires more than one resource for execution and hence can signal "Give back BinSemaphore" in case if required resources are not available with the process in the critical section.

[cowlinator]

@FrostNovaZzz , As we read in @teki 's answer, If a task tries to unlock a mutex it hasn’t locked ... the mutex is not unlocked. This means that a fast mutex is not technically a mutex, since it does allow a task to unlock a mutex it hasn't locked.

[Peter Cordes]

Even on SMP, after spinning a few times you fall-back to OS-assisted sleep/wake. (e.g. the Linux futex system call exists to assist low-latency userspace mutex / semaphore implementations. en.wikipedia.org/wiki/Futex) In the no-contention fast path, or if the resource becomes available soon, you never have the overhead of a system call. But you don't spend more than a few micro-seconds busy-waiting (spinning). Tuning the parameters of spin-loop backoff and wait is hardware and workload-dependent, of course, but the standard library usually has reasonable choices.

[Peter Cordes]

If you read the other answers, it's clear that the concept of "ownership" only makes sense with mutexes, not semaphores. Semaphores could be used for things like a thread letting other threads know that processing of a chunk of data is done; results ready to be read.

[Peter Cordes]

same functionality could be achieved through both of them. A mutex might check that it's only unlocked by the same thread that locked it, because anything else is an error for a mutex. If you want to wait until another thread has redirected stdout, or something like that, there's no obvious way to implement that with a mutex. Are you going to take / release a lock around every use of stdout? That doesn't even work, you wouldn't know whether the other thread has taken/released the mutex yet.

[Peter Cordes]

If you remove that claim, the example is maybe useful.

[Philip Couling]

This answer may be useful, but I don't see that this actually answers the question. I don't see any information on how mutexes and binary semaphores behave differently to achieve their differing intended goal. Maybe I missed something.

[evg656e]

So, in another words, mutex is a special case of binary semaphore designed solely to accomplish resource lock task. While binary semaphore can be used both for signaling and lock task, depends on how you use it.

[JacquesB]

A row of toilets would correspond to an array of mutexes, not a semaphore.

[Leponzo]

Interprocess mutexes are possible: stackoverflow.com/questions/9389730/…

[Jarrod Smith]

We should also add that in practice the additional semantics that are typically bundled with OS mutex APIs give additional information to the operating system that it can use to achieve more efficient thread scheduling. I.e. the OS can know "Thread A is waiting specifically for thread B", rather than simply "Thread A is waiting."

[starriet]

This statement contrasts with the other answers: "So in terms of binary semaphore, only the process holding the semaphore can increase the count" - Semaphore, including binary semaphore, can be released by any other thread, not only the one who acquired the semaphore. That's all the other answers are saying.