On Sun, Aug 5, 2018 at 12:12 PM, Marvin Stenger <marvin.stenge...@gmail.com> wrote: > > We talk about the implementation of chansend/recv, where fast paths are not > protected by a locked mutex (slow paths of course are). And those fast paths > use atomic.Loads intentially sparse, which could look inconsistent if not > familiar with the design/mechanics behind it. > 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.
Yes, it is definitely possible to get things wrong when combining a fast path not protected with a mutex with a slow path that is protected by a mutex. But it is also possible to get things right. Do you see a specific problem in the code? 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.
