Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Adding example on Condition Variables #347

Open
JJGO opened this issue Feb 17, 2021 · 5 comments
Open

Proposal: Adding example on Condition Variables #347

JJGO opened this issue Feb 17, 2021 · 5 comments

Comments

@JJGO
Copy link

JJGO commented Feb 17, 2021

Would you be open to having a page on Condition Variables, i.e. sync.Cond? It could go right after the mutex page and I believe it'd be a great resource since neither the go tour nor the docs have good examples/motivation on this synchronization primitive.

I'd be happy to contribute with a PR, but I thought I might ask before devoting the time to it in case the feature is considered too advanced for the tutorial.

And thanks for maintaining such a high quality learning resource!

@eliben
Copy link
Collaborator

eliben commented Feb 18, 2021

Not objecting per se, but do note that sync.Cond is considered a very specialized tool in Go. I'd venture to say that it's not very widely used, given that Go has channels. See the discussion at golang/go#20491 about the difficulty of finding an idiomatic example for its use.

@mmcgrana
Copy link
Owner

I'm open to this, but I don't think I've ever used sync.Cond in my own Go code, so I'm not sure what a good example would be, or even that there are good examples for this level of documentation. Do you want to share a specific idea for an example and we can discuss from there? Unfortunately I can't promise if it will or won't be too advanced without seeing something specific (:

@JJGO
Copy link
Author

JJGO commented Feb 26, 2021

I've used sync.Cond in scenarios where one routine needs to wake up N awaiting routines where N is unknown to the waker routine. With channels I've not found an easy way to keep waking routines without blocking the waker.

A concrete example where I've found it very idiomatic is for woker-coordinator communication where there are sequential phases of computation, for example Map Reduce.

E.g. Coordinator has both map tasks and reduce tasks, reduce tasks can only run after all map tasks are done. In this scenario workers can ask the coordinator for a task and if no more map tasks are available then the worker waits on a condition variable. Once the coordinator knows all map tasks are complete it broadcasts on the condition variable so awaiting workers can be assigned a reduce task.

My guess is that the scenario can be distilled into a more succinct example, but it'd be great to hear your thoughts first.

@eliben
Copy link
Collaborator

eliben commented Feb 26, 2021

@JJGO if you haven't seen it, I recommend checking out Bryan Mill's Rethinking Classical Concurrency patterns. The slides with speaker notes are at https://drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view -- start on page 37 for cond vars; you can also find a video of the talk online.

@peterbourgon
Copy link

Bryan takes a fairly esoteric view on what are pretty common synchronization primitives. +1 to a sync.Cond example, but be careful! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants