On Sun, Mar 17, 2019 at 1:04 PM Louki Sumirniy < louki.sumirniy.stal...@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.
