Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

[qiu laidongfeng2]

Does data race in this program affect execution results?

In amd64, it always output1.

```go

package main

import "sync"

func main() {
i := 0
var wg sync.WaitGroup
for range 1000000 {
wg.Add(1)
go func() {
defer wg.Done()
i = 1
}()
}
wg.Wait()
println(i)
}

```

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 7:04 AM 'qiu laidongfeng2' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> Does data race in this program affect execution results?
> In amd64, it always output1.

If you want to write code like this, use the sync/atomic package.
Don't write code with data races.

Ian

[qiu laidongfeng2]

I know not to write code with data races?

The problem is that I find that this code always outputs 1 on the amd64 machine,

I am not sure what effect this data competition has on the execution result,

whether it is an inevitable result of the amd64 machine to always output 1 or I am lucky to encounter that it is always output 1, so I ask.

[Robert Engels]

That is not a data race. The wait group is a synchronization barrier. 

On Jul 6, 2024, at 9:34 AM, 'qiu laidongfeng2' via golang-nuts <golan...@googlegroups.com> wrote:

I know not to write code with data races?

--
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/6a2c3ebf-b5e9-4a18-bcf3-d7a4b5fc24a4n%40googlegroups.com.

[Robert Engels]

Sorry and the outer loop is the only reader. It probably reports it as a race though since there are multiple writers - but they all write the same value. Technically still a data race depending on if the word splits when writing. 

On Jul 6, 2024, at 10:20 AM, Robert Engels <ren...@ix.netcom.com> wrote:



[Jan Mercl]

On Sat, Jul 6, 2024 at 5:21 PM Robert Engels <ren...@ix.netcom.com> wrote:

> That is not a data race. The wait group is a synchronization barrier.

Multiple concurrent, uncoordinated writers are a perfect data race.

[peterGo]

On Saturday, July 6, 2024 at 11:21:46 AM UTC-4 Robert Engels wrote:

That is not a data race. The wait group is a synchronization barrier. 

==================
WARNING: DATA RACE
Write at 0x00c000014158 by goroutine 8:
  main.main.func1()
      /home/peter/racer.go:12 +0x84

Previous write at 0x00c000014158 by goroutine 13:
  main.main.func1()
      /home/peter/racer.go:12 +0x84

Goroutine 8 (running) created at:
  main.main()
      /home/peter/racer.go:10 +0x78

Goroutine 13 (running) created at:
  main.main()
      /home/peter/racer.go:10 +0x78
==================
1
Found 1 data race(s)

peter

 

[Robert Engels]

I corrected myself. 

On Jul 6, 2024, at 10:34 AM, peterGo <go.pe...@gmail.com> wrote:



--

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/e814204e-5461-4d65-a7e7-99feaf94294an%40googlegroups.com.

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 7:34 AM 'qiu laidongfeng2' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> I know not to write code with data races?
> The problem is that I find that this code always outputs 1 on the amd64 machine,
> I am not sure what effect this data competition has on the execution result,
> whether it is an inevitable result of the amd64 machine to always output 1 or I am lucky to encounter that it is always output 1, so I ask.

I would be surprised if that program ever prints anything other than 1
in practice. But I am sometimes surprised.

Ian

> 在2024年7月6日星期六 UTC+8 22:20:57<Ian Lance Taylor> 写道：
>>
>> On Sat, Jul 6, 2024 at 7:04 AM 'qiu laidongfeng2' via golang-nuts
>> <golan...@googlegroups.com> wrote:
>> >
>> > Does data race in this program affect execution results?
>> > In amd64, it always output1.
>>
>> If you want to write code like this, use the sync/atomic package.
>> Don't write code with data races.
>>
>> Ian
>

> --
> 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/6a2c3ebf-b5e9-4a18-bcf3-d7a4b5fc24a4n%40googlegroups.com.

[burak serdar]

The way I read the section about programs with memory races
(https://go.dev/ref/mem#restrictions), that program should always
print 1.

"A read r of a memory location x holding a value that is not larger
than a machine word must observe some write w such that r does not
happen before w and there is no write w' such that w happens before w'
and w' happens before r. That is, each read must observe a value
written by a preceding or concurrent write."

i=0 happens before all i=1s, and at least one i=1 happens before the read of i.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWv7w%3DUEG0eZsZFYTpodX2cgXmXO_6QkgxeJ5A7VKDXAg%40mail.gmail.com.

[Brian Candler]

The question seems to be: "I know this is a data race, but isn't this a *safe* data race?"

To which the answer should be: "There are no safe data races".

https://docs.google.com/document/d/1WAT22FtFdMt43i3O8YrnlQTNTzZ3IoJBtu3P2DNRytg/
# was previously: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong