The Little Book of Semaphores(open.umn.edu)
open.umn.edu
The Little Book of Semaphores
http://open.umn.edu/opentextbooks/BookDetail.aspx?bookId=83
13 comments
You missed Think OS. Great intro to systems, definitely recommended for weekend reading!
Think OS: http://greenteapress.com/thinkos/
Think OS: http://greenteapress.com/thinkos/
A great guy. More interesting readings on his website (research papers, etc.:
http://allendowney.com/
Think Python is how I learned to program about 10 years ago, it was a good book.
Awesome list. The guy is a true hacker. Thanks for sharing.
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.
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
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
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.
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.
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/
http://greenteapress.com/semaphores/
Yes. The PDF link in the original article links to the same PDF on this page.
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! :)
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