The Little Book of Semaphores

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.

merlinsbrain• 12 years ago

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

nrubin• 12 years ago

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.

jestinjoy12• 12 years ago

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

jestinjoy12• 12 years ago

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

umanwizard• 12 years ago

This is not at all unusual, and I would be careful about thinking it has any predictive power.

It's extremely difficult to become a professor, so tenured or tenure-track professors at mediocre (but decent) schools often have degrees from big-name places.

Also, Olin College isn't even mediocre, just small. From what I understand it's pretty selective.

zarkov99• 12 years ago

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

kazinator• 12 years ago

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.

The Little Book of Semaphores

Related Stories