Hi, On Sat, Sep 14, 2019 at 8:28 PM Vitaly Davidovich <vita...@gmail.com> wrote: > > Unlike C++, where you can specify mem ordering for failure and success > separately, Java doesn’t allow that. But, the mem ordering is the same for > failure/success there. Unfortunately it doesn’t look like the javadocs > mention that,
Unfortunately so. > but I recall Doug Lea saying that’s the case on the concurrency-interest > mailing list (btw that’s probably the more appropriate channel for this > Java-centric question). > > For your case, it seems like an AtomicReference<Runnable> is more appropriate. But then I would have 2 volatile accesses instead of one. > terminate() sets it, then checks the count via a volatile load (or maybe it > can decrement() itself?); if zero, CAS null into the action field to > take/claim the action. decrement() likewise tries to claim the action via a > CAS. The snippet you have now would allow for concurrent action execution, > which is likely unsafe/wrong. I don't see the difference between 2 atomics and my snippet WRT concurrent execution. They can both be executed concurrently with arbitrary interleaving, no? I think my snippet is safe as long as in terminate() there is a volatile write after setting the action (it is admittedly weird to add zero just to obtain a memory effect, I could have used VarHandle.releaseFence() if I were in JDK 11), since the action would be visible from decrement() because it does a volatile read on the same variable, no? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ0gh54BKzEQcbTAyb%3DRpa41c8mpiQSGVc5xsYno-qbzVw%40mail.gmail.com.
