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 cover access to same object using a mix of 2 ways.
You can fix your code like this:
1a. change m.RLock() to m.Lock()/m.Unlock() near atomic.AddInt32(&n, 1)
because it's writing operation so you need write mutex
1b. add m.Lock()/m.Unlock near n=0 because it's writing operation as well
The, you can remove atomic ops, because now all the code is covered by
mutexes
2. Change n=0 to atomic.StoreInt32(&n, 0)
Then you can remove all mutexes, because access is covered by atomic ops
W dniu piątek, 5 lipca 2019 12:40:32 UTC+2 użytkownik White Pure napisał:
>
> 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() {
>
> 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.Unlock()
>
> }
>
> }()
>
> // do something to keep goroutines running here
>
> ......
>
> }
>
>
> Playground link: https://play.golang.org/p/fRa09l3VQob
>
>
>
--
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/ed3e8643-8781-438d-8191-1c60ee7473c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
