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.
