4 ms·
> The point is that implementing a semaphore with a mutex and condition is very easy but more versatile. Agreed. An interesting exercise is to try the reverse:
by anon946 9y ago
> The point is that implementing a semaphore with a mutex and condition is very easy but more versatile.
Agreed. An interesting exercise is to try the reverse: implementing a condition variable with a semaphore. It's not trivial to do correctly.
I teach OS, and I still cover semaphores, but I always tell the class that I don't think they are very useful. I spend much more time on condition variables.
- exDM69 9y agoThey are useful, just not in multithreaded programming. Overall I am quite disappointed at the level of education with parallelism and concurrency now that we're 15 years into the multi-core era, let alone in the years past. I'm constantly having issues with coworkers who are quite clueless in the topic, doing futile attempts in taking a textbook example and applying that to a real world problem (usually involving semaphores or trying to use atomics because "locks are hard"). It's equally frustrating to hear the "don't use locks, do CSP/message passing/concurrent collections/lock-free queues instead" cargo cult. Yes, that works for a class of problems but you still need locks to implement message passing (no excuse to not learn locking) and getting simple atomicity invariants right is as hard or harder than with locks. It takes discipline and hard work to get multithreaded programming right but there are plenty of silver bullets and snake oil being pushed.