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.
