What I meant was that if you read farther down in the synchronization section atomics are not discussed and the issue cited is related.
> On Nov 10, 2019, at 8:31 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > Ignore the first part (error!) but the issue applies in terms of atomic. > >>> 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/B86A9AAA-745B-42B1-88F6-74E656B544CE%40ix.netcom.com.
