https://g.co/kgs/2Q3a5n
> On Mar 17, 2019, at 2:36 PM, Louki Sumirniy > <louki.sumirniy.stal...@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. > > 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> >> 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. -- 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.
