Then use a mutex or atomic spin lock (although that may have issues in the current Go implementation)
> On Mar 17, 2019, at 3:56 PM, Louki Sumirniy > <louki.sumirniy.stal...@gmail.com> wrote: > > 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> >> 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. -- 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.
