Err... I think you understood the opposite. A no answer would mean this is that issue. A yes answer means the mutex is still not enough. I said yes.
On Wednesday, November 30, 2016 at 11:23:49 PM UTC+1, Ian Lance Taylor wrote: > > On Wed, Nov 30, 2016 at 2:01 PM, Daniel Fanjul > <daniel.fan...@gmail.com <javascript:>> wrote: > > 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". > > OK, I think this is https://golang.org/issue/7948. > > 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.
