The write to c.closed in closechan is *NOT* using atomic.Store. On Saturday, August 4, 2018 at 5:36:22 PM UTC-7, gra...@berkeley.edu wrote: > > I was taking a look at runtime/chan.go and noticed the following: > > - c.closed is accessed without taking c.lock in the fast paths of > chansend and chanrecv. In chansend it is accessed without using > atomic.Load, while in chanrecv it is accessed using atomic.Load. The write > to c.closed in closechan is using atomic.Store. > - something similar also is also happening with c.qcount > > > Is this intentional/safe? My understanding is that it is not safe and this > section from runtime/HACKING.md seems to agree: > > > “ > > Some common patterns that mix atomic and non-atomic access are: > > > Read-mostly variables where updates are protected by a lock. Within the > locked region, reads do not need to be atomic, but the write does. Outside > the locked region, reads need to be atomic.” > > > > It seems like reads to c.closed in both fast paths need to go through > atomic.Load and the write to c.closed in closechan needs to go through > atomic.Store. >
-- 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.
