See issue 5045 > On Feb 9, 2022, at 8:42 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > > 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/78D7693F-198F-4CDE-BEBE-C296D77111F3%40ix.netcom.com.
