On Sun, Aug 05, 2018 at 12:12:04PM -0700, Marvin Stenger wrote: > And my point was, that a slow path protected with a lock surely can execute > concurrently with a fast path not protected by that lock. So for the fast > path implementation one has to know what one is doing and if reordering > issues are a concern or not or if there could even be real data races on > the shared resource if accessed non-atomically.
An additional piece of the puzzle is probably that this particular code is distributed together with the compiler and thus is allowed to make certain assumptions with regards to its behaviour. Would it be correct for user code to do something similar and rely on it to work across different Go implementations? I don't think it's written down anywhere how atomic reads are supposed to interact with non-atomic writes. But then, the same is true for basically everything sync/atomic. -- 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.
