You are reading the section on “single go routine”. That does not apply here as there are multiple go routines. See https://github.com/golang/go/issues/5045
This is still technical undefined by the memory model. > On Nov 10, 2019, at 8:08 AM, Lars Seipel <lars.sei...@gmail.com> wrote: > > On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: >> No. Because in the absence on a memory barrier the writes may not be flushed >> meaning you cannot reason about any value ever being changed. atomics >> provide the memory barrier, but the mm still does not specify a “happens >> before” relationship (but without this they are fairly useless). > > Visibility is implied by the definition of "no concurrent access". > > This case is fully handled by the current memory model: > >> Also, if e1 does not happen before e2 and does not happen after e2, then we >> say that e1 and e2 happen concurrently. > > […] > >> That is, r is guaranteed to observe w if both of the following hold: >> 1. w happens before r. >> 2. Any other write to the shared variable v either happens before w or after >> r. > [https://golang.org/ref/mem#tmp_2] > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/165388B3-18A4-425D-8F16-B640B1894F3D%40ix.netcom.com.
