On Thu, Sep 15, 2022 at 9:11 AM Thomas Bushnell BSG <tbushn...@google.com>
wrote:
> I cannot speak to "other accepted concurrency designs" here. Simply that
> Go does not guarantee the operation you want it to, the memory model does
> not actually imply that it does, and the last sentence of the memory model
> is the most important one here: don't be clever.
>
I believe that's what we are discussing here. The way I read it, the memory
model does imply that a non-synchronized operation x sequenced before an
operation y that happened before z implies that all operations sequenced
after z happens after x.
>
> On Thu, Sep 15, 2022 at 11:08 AM robert engels <reng...@ix.netcom.com>
> wrote:
>
>> This is not what “happens before” means - at least not in any other
>> accepted concurrency designs.
>>
>> See my second example as to why.
>>
>> On Sep 15, 2022, at 10:02 AM, Thomas Bushnell BSG <tbushn...@google.com>
>> wrote:
>>
>> Happens before works just fine with atomics. But in your example, x is
>> not an atomic.
>>
>> Thomas
>>
>> On Thu, Sep 15, 2022 at 10:51 AM robert engels <reng...@ix.netcom.com>
>> wrote:
>>
>>> Yea, the race detector is broken… it fails on the following code:
>>>
>>> package main
>>>
>>> import (
>>> "sync"
>>> "sync/atomic"
>>> )
>>>
>>> func main() {
>>>
>>> var x int32
>>> var y int32
>>>
>>> w := sync.WaitGroup{}
>>> w.Add(2)
>>>
>>> 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()
>>> }()
>>> w.Wait()
>>>
>>> }
>>>
>>> The above code does not have a race, or Go doesn’t have “happens before”
>>> semantics with its atomics.
>>>
>>>
>>> On Sep 15, 2022, at 9:41 AM, Robert Engels <reng...@ix.netcom.com>
>>> wrote:
>>>
>>> To clarify, if the atomic read of Y sees the updated Y then a subsequent
>>> non-atomic read of X must see the updated X. This is a happens before
>>> relationship.
>>>
>>> The question was if the race detector understands this - I know - why
>>> not try it out…
>>>
>>> On Sep 15, 2022, at 9:39 AM, Robert Engels <reng...@ix.netcom.com>
>>> wrote:
>>>
>>>
>>> I think it needs to see the updated X - which agrees with burak.
>>>
>>> Reading Z is race.
>>>
>>> On Sep 15, 2022, at 9:24 AM, burak serdar <bser...@computer.org> wrote:
>>>
>>>
>>>
>>> On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>>> You cannot make that assumption. It's not about what the race detector
>>>> can detect.
>>>>
>>>> Goroutine one:
>>>> Writes non-synchronized X
>>>> Writes atomic Y
>>>> Writes non-synchronized Z with the value of X+Y
>>>>
>>>> Goroutine two
>>>> Reads atomic Y and sees the new value
>>>>
>>>
>>> The way I read the Go memory model, if Goroutine two sees the new value
>>> of Y, non-synchronizes writes to X by Goroutine 2 happened before Y, and
>>> thus, anything that happens after Y. This is based on:
>>>
>>> "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."
>>>
>>> And:
>>>
>>> "The happens before relation is defined as the transitive closure of the
>>> union of the sequenced before and synchronized before relations."
>>>
>>> Because:
>>> * The writes to non-synchronized X are sequenced before the atomic
>>> write to Y
>>> * The atomic read Y happened after atomic write to Y if it sees the
>>> new value
>>> * non-synchronized reads from X happen after that
>>>
>>> So that should not be a race.
>>>
>>> Am I reading this correctly?
>>>
>>>
>>>
>>>>
>>>> Can goroutine two now read non-synchronized X and assume it sees the
>>>> new value written by one? No, it cannot. There is no "happens before"
>>>> relation connecting the two writes performed by goroutine one. Requirement
>>>> one does not establish such a relationship. It only establishes that Z will
>>>> be written with the correct sum of X and Y. There must be *some *sequential
>>>> order within the context of goroutine one that sees the correct value; the
>>>> compiler is free to swap the order of the writes X and Y.
>>>>
>>>> If X were an atomic, then Requirement two would come into play. But
>>>> because X and Z are not atomic, they play no role in Requirement two. Note
>>>> that the description of atomic in the model says that writes to *atomic
>>>> *values have the property you want. And since there is no before
>>>> relationship established by any of the following text, this synchronization
>>>> cannot be relied on.
>>>>
>>>> Now you're asking whether the race detector ensures the synchronization
>>>> property you're suggesting? The race detector doesn't ensure any
>>>> synchronization properties; it detects bugs.
>>>>
>>>> I think it is capable of detecting this one.
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 14, 2022 at 11:01 PM robert engels <reng...@ix.netcom.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am working on a new project, and the race detector is reporting a
>>>>> race.
>>>>>
>>>>> Essentially, the code is
>>>>>
>>>>> var S []int
>>>>>
>>>>> several go routines write new S values using a mutex
>>>>>
>>>>> go routine Y reads S without grabbing a lock (it reads it initially
>>>>> under lock)
>>>>>
>>>>> The semantics are such that Y can operate successfully with any valid
>>>>> value of S (e.g. could be stale). (essentially S is used with copy on
>>>>> write
>>>>> semantics)
>>>>>
>>>>> The race detector reports this as a race.
>>>>>
>>>>> I could change all reads of Y to use an atomic load, but I don’t think
>>>>> it should be necessary.
>>>>>
>>>>> Is there any way to perform “lazy loads” in Go?
>>>>>
>>>>> And a follow-up:
>>>>>
>>>>> Is the race detector smart enough so that if a routines write to
>>>>> several vars (v1…n) and performs an atomic store to X, and another
>>>>> routine
>>>>> atomically reads X it can also non atomically read v1…n and it will see
>>>>> the
>>>>> stored values?
>>>>>
>>>>> This has been the long standing issue with the Go memory model and
>>>>> “happens before”… but how does the race detector report this?
>>>>>
>>>>> (Some background, the library functions fine under heavy concurrent
>>>>> stress tests - but the race detector says it is broken).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/8EC74417-C4AD-4490-9231-6E869EE72D93%40ix.netcom.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.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtd%2BpaU_BNxXDrMAN9v71r-Qhm9LcXcN2fTtjD_6oWw-Q%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtd%2BpaU_BNxXDrMAN9v71r-Qhm9LcXcN2fTtjD_6oWw-Q%40mail.gmail.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/CAMV2Rqr4vggPOWjiQg6qN0tJjhhXncKHLMCDwkqZTHBJJ7%3Dmug%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqr4vggPOWjiQg6qN0tJjhhXncKHLMCDwkqZTHBJJ7%3Dmug%40mail.gmail.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/93E2826E-1D85-48BE-BBD3-ED17F70C74F2%40ix.netcom.com
>>> <https://groups.google.com/d/msgid/golang-nuts/93E2826E-1D85-48BE-BBD3-ED17F70C74F2%40ix.netcom.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/CAMV2RqpyR_Cw4%2B593xNzLFZmAT%3DR8JXkiabX38R2ZrFO2cXBmA%40mail.gmail.com.
