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.
I was sure this was the case and this seems to confirm it: https://stackoverflow.com/a/19818448 https://play.golang.org/p/NQGO5-jCVz In this it is using 5 competing receivers but every time the last one in line gets it, so there is scheduling and priority between two possible receivers when a channel is filled. This is with the range statement, of course, but I think the principle I am seeing here is that in all cases it's either one to one between send and receive, or one to many, or many from one, one side only receives the other only sends. If you consider each language element in the construction, and the 'go' to be something like a unix fork(), this means that the first statement inside the goroutine and the very next one in the block where the goroutine is started potentially can happen at the same time, but only one can happen at a time. So the sequence puts the receive at the end of the goroutine, which presumably is cleared to run, whereas the parent where it is started is waiting to have a receiver on the other end. If there is another thread in line to access that channel, at any given time only one can be on the other side of send or receive. That code shows that there is a deterministic order to this, so if I have several goroutines running each one using this same channel lock to cover a small number of mutable shared objects, only one can use the channel at once. Since the chances are equal whether one or the other gets the channel at any given time, but it is impossible that two can be running the accessor code at the same time. Thus, this construction is a mutex because it prevents more than one thread accessing at a time. It makes sense to me since it takes several instructions to read and write variables copying to register or memory. If you put two slots in the buffer, it can run in parallel, that's the point, a single element in the channel means only one access at a time and thus it is a bottleneck that protects from simultaneous read and right by parallel threads. 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.
