A defense against killing sync.Cond, and explaining it so that more people will have it as part of their toolbox! Includes full advertisement!
Cond: A Case Study; or
Shipping Fn Channels
But first, welcome to 2018, have an ad
Three cloud vendors ruled the FaaS galaxy
We, too, have a cloud, but...
We want to be different
And users don't want to wait 4 years for native support for
their favorite programming language
And since users are developers, they may have a thing or
two to contribute
So we started building our own cloud FaaS offering, in the
open, and container native
So that we may one day rule the Galaxy
P.S. We can also pay you to work on it full time, say hi!
Onto the show
I'd like to talk to you about sync.Cond
One of the least used, reviled constructs in go
So what is this abomination?
OK, that didn't help. Why does it exist in the first place?
 Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, 30.1
Dude, show an example already
OK, but go has channels? We don't need no stinkin' cond
First, define the problem:
● Parent wait for children to finish
● Producer/Consumer problem
● Parent wait for children to finish (sync.WaitGroup)
● Producer/Consumer problem (make(chan))
So we can go home now?
OK, maybe we should define our problem
We need to allocate resources from a host (disk, memory,
CPU) dynamically per container, and when full, wait for
resources to free up.
Meanwhile, if any of the existing containers free up, we can
use them and abandon attempting to allocate more
This problem is called a covering condition
 Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, 30.3, 2015
 B.W. Lampson, D.R. Redell, Experience with Processes and Monitors in Mesa, pg. 105, 1980
But channels taste like panacea?
We need to wake up all threads when a container exits,
because multiple containers could fill its void and certain
containers may not fit at all
But you can close a channel to broadcast!
While channels can do broadcast, afterwards the channel is
closed. We really need a channel that remains open but
Mostly, it's an issue of complexity. We could implement this
all with channels, but we'd need a few things:
● requests wait over resource allocation channel
● a thread (or synchronization) that manages resource
allocation channels & their requested sizes (FIFO), and
separately receives wake up calls when resources are
freed and doles them out (and handles when allocs gave
● to figure out whatever the hell data structure ^ is
... or we can just grab a handy dandy sync.Cond
We also need to handle timeouts on <-ctx.Done()
sync.Cond and channels don't mix out of the box, so wouldn't
we be better off just doing this all with channels and get
this fo free?
What we accomplished:
● Now we can wait for resources OR a container to free up,
OR a request timeout, using a select statement
● You were duped into watching an advertisement for the
Fn Project under the false pretense that you might learn
something from somebody you have never heard of
A context, a context, my kingdom for a context?
Check us out: https://github.com/fnproject/fn
We’re hiring engineers and evangelists!
Principal Eng @ Oracle