On Sun, Oct 30, 2022 at 10:16 AM Konstantin Khomoutov wrote:
>
> | initially, y==0.
> |
> | goroutine 1:
> | x = 42
> | x = 99
> | atomic.Store(&y, 1)
> | x = 100
> |
> | goroutine 2:
> | if atomic.Load(&y) == 1 {
> |println(x)
> | }
>
> then would println have been guaranteed to still print 9
On Fri, Sep 16, 2022 at 01:26:05PM -0700, 'Keith Randall' via golang-nuts 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 progra
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 poin
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...@gm
On Fri, Sep 16, 2022 at 4:42 PM Robert Engels 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 manu
That’s a very interesting read - thank you.
Are you sure that holds when using an atomic as a memory barrier - seems it
would be very difficult for the compiler to know when it was safe to do that-
it would need to understand the atomic framing.
> On Sep 16, 2022, at 2:10 AM, Jan Mercl <0xj
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.
> On Sep 16, 2022, at 9:30 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Fri, Sep 16, 2022 at 4:23 PM Robert Engels wrote:
>
>> Norma
On Fri, Sep 16, 2022 at 4:23 PM Robert Engels wrote:
> Normally when people reply to the list it only comes from the list - and the
> list is allow listed.
All people in this thread sent their replies to both you and the list.
> You are the first person in years to say anything about this. Sor
the OP.
>
> Feel free to send me an off-list message if _you_ think it's
> necessary, but avoid a reply bot to spam my inbox, thank you.
> Otherwise I propose the admin of this list to ban your email.
>
> -- Forwarded message -
> From:
> Date: Fri,
sary, but avoid a reply bot to spam my inbox, thank you.
Otherwise I propose the admin of this list to ban your email.
-- Forwarded message -
From:
Date: Fri, Sep 16, 2022 at 9:09 AM
Subject: Re: Re: [go-nuts] Race detector question
To: Jan Mercl <0xj...@gmail.com>
On Fri, Sep 16, 2022 at 7:43 AM robert engels wrote:
> 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.
There's no such thing [in Go and many other lang
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 w
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 op
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 cannot
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 m
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
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 11:
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 main()
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.Don
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 wrot
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 race
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 wit
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 an
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 suc
24 matches
Mail list logo
