Actual difference between Mutex and Binary semaphore

0
votes

So, last week, I was researching about Mutex and Semaphores. I came to find this post which really helped me figure out what Semaphores are. Now that I understand what the theorical difference is, between Binary Semaphore and Mutex, I still wonder how to actually use them. I'm currently using C# and I can't find any way to use a Binary Semaphore in this language.

Can someone please post any (simple) code example on how to use Binary Semaphore vs Mutex ? Any widely used language would do the job. You can even post a Powershell/Bash script.

1
multithreadingthread-safetymutexsemaphorebinary-semaphore
You question title suggests you want to know about differences between them, but the body of your question asks for code examples. So what do you need? – StaceyGirl
I want to know the actual (as opposed to theorical) differences between the two. Therefore, showing a piece of code would be worth a thousand words. Though, documentation on both mutex and binary semaphore provided by a same OS/language would be relevant too... – AniMir

1 Answers

1
votes

A very coarse approximation is if your thread of execution needs to block while holding a resource (ie. mutex, sem), you shouldn't use a mutex. The problem with that approximation is that block means something different in a UI program and an interrupt handler; blocking is a relative notion.

Mutexes are bound to owners; Semaphores are not. The only agent that can release a mutex is the one that acquired it. Semaphores do not have this limitation. Because of this limitation, if a low priority agent blocks a high priority agent on a mutex, the supervisor (kernel, whatever..) can boost the priority of the owner until it relinquishes it. This can be applied transitively to solve non-cyclic priority inversion. You cannot do this with semaphores, since they lack the concept of an owner.

For example, thread 1 can acquire a semaphore, thread 2 can wait on it, and thread 3 can relinquish it. That might sound like chaos, but it might be the foundation of a more sophisticated system where thread 3 and 1 are communicating via some means, so thread 1 can hand ownership of a resource over to thread 3 directly. This can't be done with mutexes.

That said; I could like hack a pthread_mutex_transfer(mutex, pthread) into any existing implementation, thumbing my nose at the purists and theoreticians.