The loop is indeed the problem. The race detector cannot “see” that the value
being set is constant - it only sees it as a subsequent write.
Thomas was correct that there is a data race. He was incorrect that the
happens-before semantics of atomics don’t apply to non-atomic variables.
As I pointed out in the later example, you can use atomics to implement a spin
lock on non-atomic variables and it works as expected and the race detector
does not report an issue.
The paper cited on ‘benign data races” has some suspect contentions in regards
to atomic usage (ie the compiler re-using a memory address as temp storage,
because the writer could be changed to look like:
func code() {
x := 1
ready: = false
go {
a loop:
… do stuff…
if ready == false {
x = 2 // only mutate of x
atomic set ready = true
}
}
go {
atomic wait for ready == true
do something with x repeated…
}
}
The above code would still be subject to a data race because the contention is
that the compiler could use the storage for x in ‘do stuff’ which would corrupt
the x value even though it was only written once. So I believe the compiler
needs to avoid re-ordering and re-using storage in any methods where atomics
are involved - but I don’t know this for certain. i.e. The compiler cannot know
that x is the ‘exported’ value and so in the presence of atomics it cannot
perform that optimization, and if can determine it - it wouldn’t “re use” it -
so in either case it is safe.
> On Sep 16, 2022, at 4:43 PM, thepud...@gmail.com <thepudds1...@gmail.com>
> wrote:
>
> Hello Robert,
>
> I suspect the race detector does not have a bug in this case.
>
> Or at least, I suspect the issue in this example from Robert from upthead is
> the for loop on the write:
> https://go.dev/play/p/aCCvvBIrGXq <https://go.dev/play/p/aCCvvBIrGXq>
>
> > Yea, the race detector is broken… it fails on the following code:
> >
> > [snip]
> > go func() {
> > for {
> > x = 1
> > atomic.StoreInt32(&y, 1)
> > }
> > w.Done()
> > }()
> > go func() {
> > for {
> > if atomic.LoadInt32(&y) == 1 {
> > if x != 1 {
> > panic("should not happen")
> > }
> > }
> > }
> > w.Done()
> > }()
> > [snip]
>
> I think the first time through the first for loop, the write on 'x' is OK,
> but subsequent loops can have an illegal data race between writing and
> reading 'x'.
>
> In other words, I suspect this modified version with the first for loop
> removed is OK, with the atomics causing synchronization between 'x' even
> though 'x' itself is not accessed atomically:
> https://go.dev/play/p/_3S2bb61LPZ <https://go.dev/play/p/_3S2bb61LPZ>
>
> That at least passes '-race' (including with an additional outer loop added
> to give the race detector more opportunities to observe a data race).
>
> That said, maybe I have misunderstood.
>
> Informally, from the Go Memory Model blog post
> (https://research.swtch.com/gomm <https://research.swtch.com/gomm>):
>
> > The atomics in particular should be documented to provide sequentially
> consistent behavior
> > that creates happens-before edges synchronizing the non-atomic code
> around them.
> > This would match the default atomics provided by all other modern
> systems languages.
>
> More formally, from sync/atomics doc:
>
> > In the terminology of the Go memory model, if the effect of an atomic
> operation A is observed
> > by atomic operation B, then A “synchronizes before” B. Additionally,
> all the atomic operations
> > executed in a program behave as though executed in some sequentially
> consistent order. [...]
>
> and from Go Memory Model:
>
> > Requirement 1: The memory operations in each goroutine must correspond
> to a correct sequential
> > execution of that goroutine, given the values read from and written to
> memory. That execution
> > must be consistent with the "sequenced before" relation [...]
> >
> > Requirement 2: [...] The "synchronized before" relation is a partial
> order on synchronizing memory
> > operations, derived from W. If a synchronizing read-like memory
> operation r observes a synchronizing
> > write-like memory operation w (that is, if W(r) = w), then w is
> synchronized before r. [...]
> >
> > The "happens before" relation is defined as the transitive closure of
> the union of the sequenced
> > before and synchronized before relations
>
> Sorry if any of this is off base.
>
> Best regards,
> thepudds
> On Friday, September 16, 2022 at 4:26:06 PM UTC-4 k...@google.com
> <http://google.com/> wrote:
> Atomic operations can establish happens-before relationships.
>
> initially, y==0.
>
> goroutine 1:
> x = 99
> atomic.Store(&y, 1)
>
> goroutine 2:
> if atomic.Load(&y) == 1 {
> println(x)
> }
>
> This program, if it prints anything, must print 99.
> "x=99" and "atomic.Store(&y,1)" are ordered by the sequenced-before
> relationship.
> "atomic.Load(&y)" and "println(x)" are likewise.
> "atomic.Store(&y,1)" and "atomic.Load(&y)" are ordered by the
> synchronized-before relationship (if the latter in fact reads the value
> written by the former).
> So according to the memory model, the x=99 statement happens-before the
> println(x) statement.
>
> We use this pattern all the time in the runtime.
>
> That said, I'm not sure how much of atomic.* the race detector understands.
> It would not surprise me that the race detector still thinks that there is a
> race.
>
> @ThomasB, I think you're contending that the sequenced-before relationship
> doesn't order "x=99" and "atomic.Store(&y,1)". I disagree, those should be
> ordered by the sequenced-before relationship. The sequenced-before
> relationship is *almost* a total order on the execution of a single
> goroutine. The only exceptions are weird cases like the order of evaluation
> of arguments of a function call, which has some wiggle room in the spec.
> Certainly different statements are totally ordrered in the order in which
> they appear in the program execution.
>
> On Friday, September 16, 2022 at 10:51:44 AM UTC-4 ren...@ix.netcom.com
> <applewebdata://94270625-3546-49B8-8EE8-77C23A82AC00> wrote:
> Even that message came from you. It seems to me the list server is not
> configured properly - as the message should come from the list with the list
> email - and usually your name.
>
> Again, really sorry but no one has reported this to me before.
>
> > On Sep 16, 2022, at 9:46 AM, Jan Mercl <0xj...@gmail.com <>> wrote:
> >
> > On Fri, Sep 16, 2022 at 4:42 PM Robert Engels <ren...@ix.netcom.com <>>
> > wrote:
> >
> >> I don’t know what is happening. The message you just sent came from you
> >> not the list. This is not how it is supposed to work. That is why there is
> >> a problem.
> >
> > FYI, I'm posting to the list from the GMail web client. This time I
> > have manually removed you from the recipients list.
> >
> > That's all I know, sorry.
> >
> > --
> > 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/CAA40n-XK%2BMuLk5PaVsck3yJe1-gZCu1c6T_odv%2BmF0HeFB7D%3Dw%40mail.gmail.com
> >
> > <https://groups.google.com/d/msgid/golang-nuts/CAA40n-XK%2BMuLk5PaVsck3yJe1-gZCu1c6T_odv%2BmF0HeFB7D%3Dw%40mail.gmail.com>.
> >
>
> --
> 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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20cacd2f-0fd7-43b5-ba65-74e9ba008569n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/20cacd2f-0fd7-43b5-ba65-74e9ba008569n%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/209E76AB-8195-49B0-B2FF-1B81A0BF0BE4%40ix.netcom.com.
