The 2nd linked playground program appears to be identical to the program that Russ Cox's memory models part 2 blog <https://research.swtch.com/plmm> opens with: // Thread 1 // Thread 2 x = 1; while(done == 0) { /* loop */ } done = 1; print(x);
Just substitute "a" for "x", and "b" for "done" and you have recreated the same example. According to the blog, if "done" is accessed atomically, then the program is guaranteed to print 1. In eliminating data races, you benefit from the DRF-SC property, and can count on the program producing results as though it executes the source code sequentially, interleaved between the threads. Note that you don't have to access "x" atomically. It's enough to access "done" atomically to eliminate the race on "x", since its atomic access creates a memory barrier. On Monday, August 15, 2022 at 10:23:53 AM UTC-7 axel.wa...@googlemail.com wrote: > (or, to be more precise: That the order of actual execution must not be > observably different from `bar` happening after `foo`) > > On Mon, Aug 15, 2022 at 7:22 PM Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> It doesn't say that the particular sequentially consistent order is in >> any way related to the source code though. >> And yes, that's the source of the argument, as I understand it. That if >> you write `foo(); bar()`, there is supposedly no guarantee that the call to >> `bar` happens after `foo` returned. >> >> On Mon, Aug 15, 2022 at 6:50 PM jake...@gmail.com <jake...@gmail.com> >> wrote: >> >>> On Monday, August 15, 2022 at 5:20:58 AM UTC-4 ma...@changkun.de wrote: >>> >>>> > Any other reading, to me, is trying to find an ambiguity for the sole >>>> sake of finding an ambiguity. >>>> >>>> A reader does not have to be motivated to find ambiguity. If the >>>> sentence can be interpreted with different meanings, other readers may >>>> perceive it differently. To me, the first read of this sentence is >>>> perceived to be ambiguous regarding a single location or multiple >>>> locations. The posted example discusses a and b as two memory >>>> locations. >>>> >>>> Atomic operations on a and b are two different statements. It remains >>>> unclear where exactly is the sentence that tries to say this: atomic >>>> operations on different memory locations obey the program statements >>>> order within a goroutine. >>>> >>> >>> Doesn't the Section on Atomics <https://go.dev/ref/mem#atomic> >>> statement say just that: >>> >>> The APIs in the sync/atomic <https://go.dev/pkg/sync/atomic/> package >>> are collectively “atomic operations” that can be used to synchronize the >>> execution of different goroutines. If the effect of an atomic operation >>> *A* is observed by atomic operation *B*, then *A* is synchronized >>> before *B*. All the atomic operations executed in a program behave as >>> though executed in some sequentially consistent order. >>> >>> Is your confusion about the term "observed"? >>> >>> >>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/3a266d04-db5c-4e16-bf1e-3ea6c7a98168n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/3a266d04-db5c-4e16-bf1e-3ea6c7a98168n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/12288c53-394f-4ecd-ba11-44dcac2703c5n%40googlegroups.com.
