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
simultaneous concurrent access due to technical error).
But sure, changing it to eg, 3 loops with are incrementing n 100k times
would be much better example ;)
W dniu piątek, 5 lipca 2019 13:59:10 UTC+2 użytkownik Robert Engels napisał:
>
> 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 any of the observed values.
>
> On Jul 5, 2019, at 6:42 AM, Slawomir Pryczek <slawe...@gmail.com
> <javascript:>> wrote:
>
> 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 golan...@googlegroups.com <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ed3e8643-8781-438d-8191-1c60ee7473c5%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/ed3e8643-8781-438d-8191-1c60ee7473c5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
--
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/2c33216c-eac9-40b8-92d9-b25a3455bb83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
