I didn't mention actually excluding access by passing data through values either, this was just using a flag to confine accessor code to one thread, essentially, which has the same result as a mutex as far as its granularity goes.
On Sunday, 17 March 2019 13:04:26 UTC+1, Louki Sumirniy 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. > > I think the way they work is that there is queues for read and write > access based on most recent, so when a channel is loaded, the most > proximate (if possible same) thread executes the other side of the channel, > and then if another thread off execution bumps into a patch involving > accessing the channel, if the channel is full and it wants to fill, it is > blocked, if it wants to unload, and it's empty, it is blocked, but the main > goroutine scheduler basically is the gatekeeper and assigns exeuction > priority based on sequence and first available. > > So, if that is correct, then the version with the load after the goroutine > and unload at the end of the goroutine functions to grab the thread of the > channel, and when it ends, gives it back, and if another is ready to use > it, it is already lined up and the transfer is made. So any code I wrap > every place inside the goroutine/unload-load pattern (including inside > itself) can only be run by one thread at once. If you ask me, that's better > and more logical than callbacks. > > On Sunday, 17 March 2019 11:05:35 UTC+1, Jan Mercl wrote: >> >> >> On Sun, Mar 17, 2019 at 10:49 AM Louki Sumirniy <louki.sumir...@gmail.com> >> wrote: >> >> > I just ran into my first race condition-related error and it made me >> wonder about how one takes advantage of the mutex properties of channels. >> >> I'd not say there are any such properties. However, it's easy to >> implement a semaphore with a channel. And certain semaphores can act as >> mutexes. >> >> > If I understand correctly, this is a simple example: >> >> That example illustrates IMO more of a condition/signal than a typical >> mutex usage pattern. >> >> -- >> >> -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.
