The Little Book of Semaphores

The author Alan B. Downey has released quite a few free books:

Check out http://www.greenteapress.com/ including:

Think Python : http://www.greenteapress.com/thinkpython/thinkpython.html

Think Bayes : http://www.greenteapress.com/thinkbayes/index.html

Think Complexity : http://www.greenteapress.com/complexity/index.html

Think Stats : http://www.greenteapress.com/thinkstats/index.html

Yikes! I'm appalled by the one-sided justification for semaphores in this book. (2.3, "Why semaphores?")

Semaphores are actually a horrible primitive for building concurrency. I sometimes call them "the goto of synchronization", which is deliberately ironic since they are a gift to the world from the "goto considered harmful" thinker, Dijkstra.

Debugging a problem with semaphores is difficult because they have no useful state beyond their count. You don't know how a set of semaphores might have gotten into a given state. (Vaguely analogous to the the argument that in a spaghetti program with backward gotos, it's difficult to have an idea of how control arrived at a particular node in the program.)

For instance, when we (ab)use a semaphore to simulate a mutex, that semaphore does not actually track the ownership: who is locking it now? It can be signaled by any task at all, whereas a proper mutex can diagnose the fact that it is unlocked by its owner.

Semaphores most certainly do not impose deliberate constraints that avoid programmers avoid errors, whatever that is supposed to mean, ouch!

When higher level primitives are correctly built on semaphores (condition variables, read-write locks, you name it), the solutions look like Rube Goldberg mousetraps. And that's before additional requirements are added like error checking, or handling priority inversion and whatnot.

Semaphores have one very good application and that is a situation in which a very fragile context (such as an interrupt service routine) needs to generate a wakeup signal. The semaphore signal operation can be made reentrant fairly easily. This is not only true in OS kernels. Note that in POSIX, for instance, the sem_post operation is noteworthy for being async-signal-safe, meaning that it can be called from a signal handler. By contrast, other things like pthread_cond_signal cannot be.

Seems interesting. IME, This is one of the topics that people who didn't do CS (and even people who did) tend to struggle with and get tripped up on in practice. I think I'm going to get this book and if it's good, I'll probably be recommending it to some folks. Glad to see Dining Philosophers mentioned - it was one of my favorite problems in school and it's a great allegory for resource sharing problems.

Interesting thing is, his place of work is not famous as compared to top US institutions (I am from outside US). But his educations says it

Ph.D. Computer Science, University of California at Berkeley, May 1997 . M.S. Civil Engineering, Massachusetts Institute of Technology, August 1990. B.S. Civil Engineering, Massachusetts Institute of Technology, June 19 89

Allen taught every single software class I took in college,its awesome to see his writing recognized on HN! We actually worked through LBoS during a software systems course this past spring semester, it was a great way to get introduced to the complexities of multithreaded programs.

This book is a must read. Helped me a lot score high at the exams for my operating systems exam.

Isn't it the same book?

http://greenteapress.com/semaphores/

This is a really nice book on concurrency. Clear, detailed and assuming very little knowledge on the part of the reader.

The best I have seen about semaphores. I am using this in my course. It helped me to explain concepts simple and clear

A great book which cleared a lot of my concepts about OS back in school. Re-read is due!

I recognize the author, Downey. He's usually very clear in his explanations.

Looks very nicely written.

Thought it was a book about flags first, but this is waaaay better! :)