The problem with this reasoning is that Go still does not have an explicit memory model with respect to happens before relationships - falling back on “whatever the current implementation behavior is”. This makes it more likely that any change in the compiler will need to continue to support the benign data races.
> On Feb 9, 2022, at 8:25 AM, peterGo <go.peter...@gmail.com> wrote: > > > Pelen Li, > > Boehm covers your specific case: "there is no reason to believe that a > currently working program with “benign races” will continue to work when it > is recompiled. Perhaps most surprisingly, this includes even the case of > potentially concurrent writes of the same value by different threads." > > Peter > >> On Wed, Feb 9, 2022 at 9:17 AM peterGo <go.peter...@gmail.com> wrote: >> Pelen Li, >> >> Always fix your data races. You should consider the results of data races as >> undefined. >> >> Dmitry Vyukov, who implemented the Go race detector, once wrote an >> interesting article with the title: "Benign data races: what could possibly >> go wrong?" >> >> https://twitter.com/dvyukov/status/288858957827682304 >> >> The Go Blog: Introducing the Go Race Detector >> Dmitry Vyukov and Andrew Gerrand >> 26 June 2013 >> >> https://go.dev/blog/race-detector >> >> Hans-J. Boehm wrote: "there is no reason to believe that a currently working >> program with “benign races” will continue to work when it is recompiled." >> >> How to miscompile programs with “benign” data races >> Hans-J. Boehm >> HP Laboratories >> >> https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf >> >> Nonetheless many programmers clearly believe, along with [15] that certain >> kinds of data races can be safely ignored in practice because they will >> produce expected results with all reasonable implementations. Here we show >> that all kinds of C or C++ source-level “benign” races discussed in the >> literature can in fact lead to incorrect execution as a result of perfectly >> reasonable compiler transformations, or when the program is moved to a >> different hardware platform. Thus there is no reason to believe that a >> currently working program with “benign races” will continue to work when it >> is recompiled. Perhaps most surprisingly, this includes even the case of >> potentially concurrent writes of the same value by different threads. >> >> And so on. >> >> Peter >> >>> On Wednesday, February 9, 2022 at 3:21:26 AM UTC-5 penglo...@gmail.com >>> wrote: >>> I want to set a value with the index of the slice. I don't really care if >>> there are multiple goroutines cover the value with each other, because the >>> value is same. >>> >>> Can i just ignore this DataRace Warning? I don't know if this will cause >>> panic. >>> >>> Here's my example: >>> I defined a structure with slice, and a Add() function for it. sample like >>> this: >>> ```go >>> package test_slice >>> >>> type SliceObj struct { >>> set []uint >>> } >>> >>> func New(length int64) *SliceObj { >>> return &SliceObj{ >>> set: make([]uint, length), >>> } >>> } >>> >>> func (b *SliceObj) Add(i uint) { >>> b.set[i] = i >>> } >>> ``` >>> >>> And then i make a main file to test it, like this: >>> ```go >>> package main >>> >>> import ( >>> "time" >>> >>> "test_slice" >>> ) >>> >>> func main() { >>> s := test_slice.New(1000000) >>> go func() { >>> s.Add(10) >>> }() >>> s.Add(10) >>> >>> time.Sleep(3 * time.Second) >>> } >>> ``` >>> >>> And data race is detected: >>> (I know the reason of this warning, but I don't know if I can ignore it) >>> ================== >>> WARNING: DATA RACE >>> Write at 0x00c000180050 by goroutine 18: >>> test_slice.(*SliceObj).Add() >>> test_slice.go:27 +0x68 >>> main.main.func1() >>> test.go:25 +0x36 >>> >>> Previous write at 0x00c000180050 by main goroutine: >>> test_slice.(*SliceObj).Add() >>> test_slice.go:27 +0xfd >>> main.main() >>> test.go:27 +0xcb >>> >>> Goroutine 18 (running) created at: >>> main.main() >>> test.go:24 +0xca >>> ================== >>> Found 1 data race(s) >>> exit status 66 >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/ai0eQtnas7A/unsubscribe. >> To unsubscribe from this group and all its topics, 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/2594a018-872a-4d54-8ede-c769042e99b5n%40googlegroups.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/CAOBWp8do4njo%2B56hb7PJ-4RdXxV%2B0KGUVwv9zRC%3Dgd3bm%2BSM_g%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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/54D9306A-530F-4BB2-949F-295654FA3A2B%40ix.netcom.com.
