I just ran into my first race condition-related error and it made me wonder about how one takes advantage of the mutex properties of channels.
If I understand correctly, this is a simple example: mx := make(chan bool) // in separate scope, presumably... go func() { <-mx doSomething() }() mx <- true So what happens here is the contents of the goroutine are waiting on something to come out of the channel, which is executed in parallel, or in sequential order, the content of the goroutine doesn't start until the channel is loaded, which happens at the same time, so it's impossible for two competing over the same lock to hold it at the same time. If we have one thread, I think the goroutine runs first, it hits a block, and then the main resumes which blocks loading the other one, so if another thread also tries to wait on that channel it will be second (or later) in line waiting on that channel to pop something out. I can see there is also another strategy where the shared memory is the variable passing through the channel (so it would also probably be a chan *type as well, distinguishing it), and the difference and which to choose would depend on how many locks you want to tie to how many sensitive items. If it's a bundle of things, like a map or array, then it might be better to pass the object around with its pointers, using channels as entrypoints. But more often it's one or two out of a set of other variables so it makes more sense to lock them separately, and with channels each lock would be just one extra (small) field. Or maybe I am saying that backwards. If the state is big, use a few small locks to cover each part of the ephemeral shared state, if the state is small, pass it around directly through channels. I'm really a beginner at concurrent programming, I apologise for my noobishness... and thanks to anyone who helps me and anyone understand it better :) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.