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 wrote:
>
>
>
>> On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts
>> wrote:
>> You cannot make that assumption. It's not about what the
The only alternatives that I see would each introduce an extra call to Add,
like the below. I'm not sure if this is much less "clunky", but it at least
avoids the reassignment to s.
func collectStringsetMap(m map[string]*stringset.Set, key string, value
...string) *stringset.Set {
if s, ok :=
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(, 1)
}
Thanks for the solution
I want to know what I need to add in my code other than the library
mentioned on top. How can I add the implementation in my code? I have a TCP
connection and would want to do something with setdeadline class only.
Regards,
Himani Arora
On Thu, Sep 15, 2022 at 5:39 AM
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
Can goroutine two now read non-synchronized X
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
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
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
wrote:
> Yea, the race detector is broken… it fails on the following code:
>
> package main
>
> import (
>"sync"
>"sync/atomic"
> )
>
> func
On Thu, Sep 15, 2022 at 9:19 AM Thomas Bushnell BSG
wrote:
> On Thu, Sep 15, 2022 at 11:16 AM robert engels
> wrote:
>
>> This is simply incorrect. The ‘issue’ about clarifying the memory has
>> been about “happens before” since the beginning. The model was clarified.
>> The race detector
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.
On Thu, Sep 15, 2022 at
On Thu, Sep 15, 2022 at 9:21 AM Thomas Bushnell BSG
wrote:
> On Thu, Sep 15, 2022 at 11:19 AM burak serdar
> wrote:
>
>> On Thu, Sep 15, 2022 at 9:11 AM Thomas Bushnell BSG
>> wrote:
>>
>>> I cannot speak to "other accepted concurrency designs" here. Simply that
>>> Go does not guarantee the
Well, what the Go memory model says is this:
"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, defined as the partial
On Thu, Sep 15, 2022 at 9:11 AM Thomas Bushnell BSG
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
After some analysis and discussion, the sample I provided earlier has a data
race by definition - although in many cases these are benign and do no affect
the correctness of the program. E.g. the program may be “sampling” and so any
valid value read is “ok”. In detail, because of the loop, the
14 matches
Mail list logo
