The author Alan B. Downey has released quite a few free books:<p>Check out <a href="http://www.greenteapress.com/" rel="nofollow">http://www.greenteapress.com/</a> including:<p><i>Think Python</i> : <a href="http://www.greenteapress.com/thinkpython/thinkpython.html" rel="nofollow">http://www.greenteapress.com/thinkpython/thinkpython.html</a><p><i>Think Bayes</i> : <a href="http://www.greenteapress.com/thinkbayes/index.html" rel="nofollow">http://www.greenteapress.com/thinkbayes/index.html</a><p><i>Think Complexity</i> : <a href="http://www.greenteapress.com/complexity/index.html" rel="nofollow">http://www.greenteapress.com/complexity/index.html</a><p><i>Think Stats</i> : <a href="http://www.greenteapress.com/thinkstats/index.html" rel="nofollow">http://www.greenteapress.com/thinkstats/index.html</a>
Yikes! I'm appalled by the one-sided justification for semaphores in this book. (2.3, "Why semaphores?")<p>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.<p>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.)<p>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.<p>Semaphores most certainly do not <i>impose deliberate constraints that avoid programmers avoid errors</i>, whatever that is supposed to mean, ouch!<p>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.<p>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<p>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.
Isn't it the same book?<p><a href="http://greenteapress.com/semaphores/" rel="nofollow">http://greenteapress.com/semaphores/</a>