Thanks for your reply.
I've tried before and it reported race.
But I don't understand why this code has race, and what's the possible bug?
Here's the output:
$ go run -race main.go
==
WARNING: DATA RACE
Write at 0x00c96000 by goroutine 7:
main.main.func3()
/Users/purewh
unc() {
for {
m.Lock()
n = 0
m.Unlock()
}
}()
go func() {
for {
m.Lock()
n -= 1
m.Unlock()
}
}()
}
Playground link: https://play.golang.org/p/Mrdetw46mXR
在 2019年7月5日星期五 UTC+8下午6:40:32，White Pure写道：
>
> Hi,
> I wrote some code like below these days, and my colleagues and me are
>
Hi,
I wrote some code like below these days, and my colleagues and me are
not sure if the code has any concurrent problem.
Can someone help to figure out if the code has any race problem?
Thanks very much!
Code:
> package main
> import (
"sync"
"sync/atomic"
)
> func main
plete example: https://play.golang.org/p/vWVXzRBPMNe
> The question is: according to the Go memory model, what's the set of
> possible things that that program can print?
>
> I think it could print "unexpected value 0" but not "unexpected value 2".
>
>
&g
Hi,
Thanks for your reply.
The second bug is a known issue, so let’s ignore that. In that case, I
think function f still can only be executed once.
But why does the load and store of o.done need to be done using atomic
operations? I suppose there’s mutex assuring the happens-before.
