3 ms·
I overall like this article and share your admiration for semaphores; however this part ain't so: > there’s not much theoretical benefit to such a binary semap
by ridiculous_fish 4y ago
I overall like this article and share your admiration for semaphores; however this part ain't so:
> there’s not much theoretical benefit to such a binary semaphore over a mutex – in fact, they’re interchangeable
Not interchangeable!
A binary semaphore has a superpower over a mutex: the lock-taker ("decrementer") can be disconnected from the lock-releaser ("incrementer"). You may wait for a thing and later be notified of the thing, but the notification comes on another thread, or in a signal handler, etc. But mutexes cannot handle locking in one thread and being unlocked somewhere else. Binary semaphores handle this fine; in this way they share something in common with condvars and also with mutexes.
The article calls this the "ugly part": how do you handle release()? But that's the source of a semaphore's power!
- Salgat 4y agoThat's a specific type of mutex. Mutexes and single count Semaphores can absolutely be the same thing depending on the implementation. Similar to how some mutexes can be re-entrant but not always.
- ridiculous_fish 4y agoFascinating. What mutex allows being released from another thread? I believe you they exist, I have just never heard of such a thing.
- ComputerGuru 4y agoNot the one you're replying to, but it depends on what you mean by "allows." If you don't mean "in its spec" but "in practice, as written and most commonly used" then the pthread mutex fits that definition, at least under Linux, as noted in a footnote in the article: > You can see a sample application testing for pthread_mutex_unlock() safety > here [0] and try it out for yourself online here [1]. [0]: https://gist.github.com/mqudsi/5aac71d8177866ba2762bda01a3ff21a https://gist.github.com/mqudsi/5aac71d8177866ba2762bda01a3ff... [1]: https://onlinegdb.com/9hmNhBuEc https://onlinegdb.com/9hmNhBuEc You can literally use it as a binary semaphore, but I can't think of a good reason to do so since pthread semaphores are signal safe while pthread mutexes aren't (which is why many people do the opposite). The only way it can not work that way is to keep track of the owning thread id, which it elides as an optimization and trusts the caller to "use it wisely" instead. Using PTHREAD_MUTEX_ERRORCHECK instead of PTHREAD_MUTEX_NORMAL (which pretty much every platform I've seen defaults to as the value of PTHREAD_MUTEX_DEFAULT) causes that to fail, but when's the last time you ran into a project using PTHREAD_MUTEX_ERRORCHECK? (PTHREAD_MUTEX_RECURSIVE technically has the information required to also validate the unlocking thread, but I haven't tried to see if does in practice.)
- ridiculous_fish 4y agoVery interesting, TIL, thank you.
- ComputerGuru 4y agoCheers! (This is mqudsi, btw)