The Little (Go) Book of Semaphores


I’ve been thinking for a while about “porting” The Little Book of Semaphores to Go. What I mean by that is taking the examples and problems presented in the book and implementing them in idiomatic Go. With that goal in mind, I started a blog where I expect to present the material as I develop it. While I don’t rule it out, for the moment my goal is not to (partially) rewrite the book (although the license does allow for that). My immediate goal is to provide a “transition guide”, as some of the patterns presented in the book are generally applicable.

The relevant posts can be found at; I will welcome any feedback!



I love this idea!

For the past few weeks I’ve been looking around at some of the confusion that newbies to the language have, and there’s quite a bit of it in the are of mutexes and semaphores. Having a good go-specific resource would be lovely.

1 Like

Oh, hey! You linked to my blog post with the exercises :)

I will definitely be following along as you develop this series. I’m very pleased to see this.


Hi Marcello.

You should like this code “fragment” about semaphore in Go.


I thought it made me think about semaphores…

I will follow your progress and if I have time will contribute.


1 Like

Hi Marcello.
I have just added 2 solutions to the TBLOS: the rendezvousSemaphore one should interest you.

The lunchSemaphore one is inspired by your lunch study.

Looking forward to your feed-back.


1 Like

Thanks Patrick!

Hi Marcello.

I have just added another solution to the TBLOS: the barrierSemaphore in Go.


Enjoy this week-end.

Looking forward to your feed-back.


Another post in the series, going back to basics and examining a very basic semaphore implementation:

Excellent little article. Very clear.
I am preparing an example about ‘cyclic barrier’. I will use this latter semaphore implementation with sync.Cond. Just done a quick benchmark, 20.4ns on Decrease()/Increment() (Acquire/Release) with it and 21.6ns with the robryk implementation (just for the record).

Good idea. Hope to read about when to use sync.Cond

@pmjtoca, will you explain this too in your cyclic barrier example?

^ ernest

1 Like

Hi all.

I have added 2 ‘cyclic barrier’ (could be applied to Matrix computation - rows as ‘parties’) examples, one using ‘sync.Cond’ and another using a ‘Mutex/Chan’.

Fragment here:
and here:

Hope these 2 examples help exploring Go signalling with the ‘sync’ package primitives.

@emicklei: Regarding, the question: “when to use sync.Cond ?”. Well, I would say after all options in sync have been exhausted (WaitGroup is quite useful) and when a ‘condition/event’ state is to be modified atomically (happens safely) and is to trigger a ‘release’ on other waiting ‘threads/goroutines’ (ie signalling when a condition is safely satisfied), but I do not know whether saying this, this way, answer anything (I will try to figure out a more pertinent example). “Cyclic barrier” tries to show a situation when sync.Cond is really an efficient signalling scheme.

Complement: Channels are inherently hazard safe, and blocking and signaling are done automatically, simpler to use than Sync.Cond which is a lower level primitive requiring to manage ‘safely’ acquiring and releasing locks and signalling. To be used when a fine-grained control is necessary (when dealing with multiple consumer threads, to control pool of threads).

See condition variable article in Akhter, S., & Roberts, J. (2006). Multi-Core Programming: Increasing Performance through Software Multi-threading. Intel Press. According to them “The condititon variables are preferable to locks when pooling requires and needs some scheduling behavior among threads”.

The standard library uses ‘sync.Cond’ in ‘crypto/buffer.go’, signalling one at a time (no broadcast) in a producer(Writer signal())/consumer(Reader(s) wait() until buffer contains something…) scheme. See here:

I am preparing an example about the Dining Philosophers problem. And just read an interesting paper “the Driving Philosophers”, an attempt to generalize the Dining Philosophers, see here:

1 Like

I published my Go solution to the Dining Philosophers a couple of weeks ago. I’d love to see what you came up with, Patrick.

I played with some variations of the solution (is a fork a channel? a goroutine? a piece of data?) and I settled down on the one presented in the blog post. I tried to not stray away too much from the original problem, but after thinking about it, I feel the original problem is designed with a semaphore solution in mind.

Awesome idea. I’ll be checking them out!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.