I was going to answer no, but after a careful review of the go memory model section regarding locks, I am replying: yes, I would.
Because the memory model only specifies "happens before" restrictions between calls to Lock() and Unlock() and that is not this case. "For any sync.Mutex or sync.RWMutex variable l and n < m, call n of l.Unlock() happens before call m of l.Lock() returns." "For any call to l.RLock on a sync.RWMutex variable l, there is an n such that the l.RLock happens (returns) after call n to l.Unlock and the matching l.RUnlock happens before call n+1 to l.Lock." The inner most goroutine would run the assignment and a call to l.Lock() or l.Unlock(). You can still swap the actions and "the [resulting] reordering does not change the behavior within that goroutine as defined by the language specification". On Wednesday, November 30, 2016 at 10:40:34 PM UTC+1, Ian Lance Taylor wrote: > > Would you apply the same argument to calls to the Lock and Unlock > methods of a sync.Mutex? After all, the original code could be > rewritten to use Lock and Unlock calls, and presumably that would be > OK. > > If you agree with that, then I think it is sufficient to say that > WaitGroup is implemented using sync.Mutex. > > Ian > -- 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. For more options, visit https://groups.google.com/d/optout.
