This was a good link to follow: https://en.wikipedia.org/wiki/Bulk_synchronous_parallel
led me here: https://en.wikipedia.org/wiki/Automatic_mutual_exclusion and then to here: https://en.wikipedia.org/wiki/Transactional_memory I think this is the pattern for implementing this using channels as an optimistic resource state lock during access: // in outside scope mx := new(chan bool) // routine that needs exclusive read or write on variable: go func() { for { somestate := doSomething() <-mx if currentState() == somestate { break } } } mx <- true This is not a strict locking mechanism but a way to catch access contention. somestate might be a nanosecond timestamp or a value that is only read and always incremented by every accessor, signifying the number of accesses and thus the synchronisation state before the channel is emptied can be compared to after, and if no other access incremented that value then it knows it can continue with the state being correctly shared. I am deeply fascinated by distributed systems programming and this type of scheduling system suits better dealing with potentially large and complex state (like a database) is to take note of access sequence. If we didn't have the possibility of one central counter that only increments, the event could be tagged with a value that derives out of the event that called it and the result of the next event. As my simple iterative example showed, given the same sequence of events, channels are deterministic, so this is an approach that is orthogonal but in the same purpose - to prevent multiple concurrent agents from desynchronising shared state, without blocking everything before access. It's not a journal but the idea is to have each goroutine acting on the final state of the value at the time it is invoked to operate on it. So you let everyone at it but everyone stops at this barrier and checks if anyone else changed it and then they try again to have a conflict free access. On Sunday, 17 March 2019 20:52:12 UTC+1, Robert Engels wrote: > > https://g.co/kgs/2Q3a5n > > On Mar 17, 2019, at 2:36 PM, Louki Sumirniy <louki.sumir...@gmail.com > <javascript:>> 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...@googlegroups.com <javascript:>. > 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.
