Without reading too deeply, and only judging based on your statements, it seems you are confusing implementation with specification. The things you cite are subject to change. You need to reason based on the specification not the observed behavior. Then use the observed behavior to argue that it doesn’t meet the specification.
> On Mar 17, 2019, at 3:50 PM, Louki Sumirniy > <louki.sumirniy.stal...@gmail.com> wrote: > > https://play.golang.org/p/Kz9SsFeb1iK > > This prints something at each interstice of the execution path and it is of > course deterministic. > > I think the reason why the range loop always chooses one per channel, last > one in order because it uses a LIFO queue so the last in line gets filled > first. > > The example in there shows with 1, 2 and 3 slots in the buffer, the exclusion > only occurs properly in the single slot, first goroutine always sends and > second always receives. This is because of the order of execution. If the > sends were externally determined and random it still only gets written within > one location. If you only read and write these variables inside this loop > they can never be clobbered while you read them, which is the contention that > a mutex is for determining the sequence of execution. > > The main costs I see are that though the overhead is lower, there is still > overhead so there is some reasonable ratio between the amount of code you > execute in a given moment is shorter the other competing parallel threads > with external, not-deterministic inputs will lock the value for not longer > than you want to avoid with adding response latency. The scheduling overhead > escalates with the number of threads and costs also in memory. > > But my main point is that it functions correctly as a mutex mechanism and > code inside the goroutine can count on nobody else accessing the variables > that are only read and written inside it. > >> On Sunday, 17 March 2019 20:36:40 UTC+1, Louki Sumirniy 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.
