On Sat, Sep 14, 2019 at 6:01 PM Simone Bordet <[email protected]> wrote:
> Hi, > > On Sat, Sep 14, 2019 at 8:28 PM Vitaly Davidovich <[email protected]> > 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 But only in the (presumably) slowpath? I’m assuming terminate() is infrequent. decrement() won’t look at the AR unless it decrements to 0. > . > > > 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? In your snippet, terminate() sets the field - it can be visible immediately (or terminate() thread is descheduled). decrement runs, decrements to 0, sees action != null. terminate() also now sees 0, and likewise proceeds to run the action. The AR I was suggesting would allow ownership protocol over the action. Read it, if not null, try to CAS a null in there. If CAS succeeds, you’ve claimed ownership. If it fails, someone else claimed it. Whoever claims it runs the action. There may be a better approach, depends on a bit more details of the use cases. > > > 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 [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ0gh54BKzEQcbTAyb%3DRpa41c8mpiQSGVc5xsYno-qbzVw%40mail.gmail.com > . > -- Sent from my phone -- 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37FeAUgqj96HkfJRywBoxCdDCf%3D19ufjq60DE7CtVKXvZw%40mail.gmail.com.
