I am pretty sure the main cause of deadlocks not having senders and receivers in pairs in the execution path such that senders precede receivers. Receivers wait to get something, and in another post here I showed a playground that demonstrates that if there is one channel only one thread is every accessing them (because the code has those variables only accessed in there). In a nondeterministic input situation where a listener might trigger a send (and run this protected code), it is still going to be one or another is in front of the queue, in this case we are not concerned with sequence only excluding simultaneous read/write operations.
I would not use a buffered channel to implement a mutex, as this implicitly means two or more threads can read and write variables inside the goroutine. That was my main question, as I want to use the lightest possible mechanism to simply control that only one reader or writer is working at one moment on two variables. that the race detector is flagging in my code. On Sunday, 17 March 2019 20:51:33 UTC+1, Jan Mercl wrote: > > On Sun, Mar 17, 2019 at 8:36 PM Louki Sumirniy <louki.sumir...@gmail.com > <javascript:>> wrote: > > > So I am incorrect that only one goroutine can access a channel at once? > I don't understand, only one select or receive or send can happen at one > moment per channel, so that means that if one has started others can't > start. > > All channel operations can be safely used by multiple, concurrently > executing goroutines. The black box inside the channel implementation can > do whatever it likes as long as it follows the specs and memory model. But > from the outside, any goroutine can safely send to, read from, close or > query length of a channel at any time without any explicit synchronization > whatsoever. By safely I mean "without creating a data race just by > executing the channel operation". The black box takes care of that. > > However, the preceding _does not_ mean any combination of channel > operations performed by multiple goroutines is always sane and that it > will, for example, never deadlock. But that's a different story. > > -- > > -j > -- 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.
