Interesting point because output would be random but still n could be
accessed by only one thread at a time, after the change ... so technically
it's different kind of a race (race due to the order in which operations
are scheduled because they can not be safely serialized, not due to
simultane
Even if you do this, the code still has a “race” as there is no way to
logically reason as to the eventual outcome or purpose. You can take out all of
the concurrent controls and you’ll have the same program/result (although the
race detector will report an issue) - no claims can be made about a
Sure it has a race issue, because in this example you're mixing atomic
operations with mutex, when you want your code to be thread safe you need
to do access to the variable using mutex or using atomic in all cases.
Because both ways work differently and are not "interchargable" so you
can't co
Sorry for miss some code, the code should be like this:
package main
import (
"sync"
"sync/atomic"
)
func main() {
var n int32
var m sync.RWMutex
go func() {
for {
atomic.LoadInt32(&n)
}
}()
go func() {
for {
m.RLock()
atomic.AddInt32(&n, 1)
m.RUnlock()
}
}()
go func() {
for {
m.Lock()
n = 0
m.U
