https://play.golang.org/p/13GNgAyEcYv
I think this demonstrates how it works quite well, it appears that threads stick to channels, routine 0 always sends first and 1 always receives, and this makes sense as this is the order of their invocation. I could make more parallel threads but clearly this works as a mutex and only one thread gets access to the channel per send/receive (one per side). On Sunday, 17 March 2019 14:55:58 UTC+1, Jan Mercl wrote: > > On Sun, Mar 17, 2019 at 1:04 PM Louki Sumirniy <louki.sumir...@gmail.com > <javascript:>> wrote: > > > My understanding of channels is they basically create exclusion by > control of the path of execution, instead of using callbacks, or they > bottleneck via the cpu thread which is the reader and writer of this shared > data anyway. > > The language specification never mentions CPU threads. Reasoning about the > language semantics in terms of CPU threads is not applicable. > > Threads are mentioned twice in the Memory Model document. In both cases I > think it's a mistake and we should s/threads/goroutines/ without loss of > correctness. > > Channel communication establish happen-before relations (see Memory > Model). I see nothing equivalent directly to a critical section in that > behavior, at least as far as when observed from outside. It was mentioned > before that it's possible to _construct a mutex_ using a channel. I dont > think that implies channel _is a mutex_ from the perspective of a program > performing channel communication. The particular channel usage pattern just > has the same semantics as a mutex. > > -- > > -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.
