[concurrency-interest] jdk9 VarHandle and Fence methods

Vitaly Davidovich vitalyd at gmail.com
Sat Aug 22 14:15:40 EDT 2015


I would hope there's no ordering difference between successful and
unsuccessful CAS.  On x86/64 the instruction itself provides full fence
irrespective of outcome; compiler doesn't know a priori whether it will
succeed or not.  Are there platforms where the lowering of the CAS has
different cpu ordering based on outcome? LL/SC can fail if cacheline is
modified in between (even if value is still the expected one) but I'm not
aware of that changing ordering semantics.  However, if there are cases
where this would matter, I hope the JVM ensures the requested ordering
irrespective of outcome.

Along this line, the more "interesting" and related question is what the
ordering guarantees are for failed tryLock methods.

sent from my phone
On Aug 22, 2015 1:41 PM, "thurstonn" <thurston at nomagicsoftware.com> wrote:

> Thanks for the prompt reply.  I guess I'll operate then from the yes
> perspective.
>
> What are the plans with respect to the "higher-order methods" on e.g.
> AtomicReference, i.e.
>
> T getAndAccumulate(T, BinaryOperator<T>)
> T updateAndGet(UnaryOperator<T>)
> . . .
> etc.
>
>
> Are you going to have:
> T getAndAccumulateVolatilely(T, BinaryOperator<T>)
> T getAndAccumulateAcquiredly(T, BinaryOperator<T>)
> etc versions?
>
>
> That seems like a pollution of the API, IMO (and just awful names).  And
> I'm
> not really sure where it ends.
>
> And then a small javadoc modification suggestion:
> /**
>       * Returns the value, and ensures that subsequent loads and stores
>       * are not reordered before this access.
>       *
>       * @apiNote Ignoring the many semantic differences from C and
>       * C++, this method has memory ordering effects compatible with
>       * memory_order_acquire ordering.
>       *
>       * @return the value
>       */
>      T getAcquire(Object owner);
>
> I find
> /**
>       * Returns the value, and ensures that subsequent loads and stores
> (*in
> the program order*)
>       * are not reordered before this access.
>       *
>       * @apiNote Ignoring the many semantic differences from C and
>       * C++, this method has memory ordering effects compatible with
>       * memory_order_acquire ordering.
>       *
>       * @return the value
>       */
>      T getAcquire(Object owner);
>
> to be a little clearer as *subsequent* is an overloaded term when it comes
> to JMM matters.
>
> And one final question that I've always been confused about;  are there
> different "memory ordering effects" between a successful CAS and an
> unsuccessful one (presumably in the latter because no write actually
> occurs)?
> IIRC, when looking at the java 8 JVM code, I believe a fence was inserted
> in
> the successful case, at least on x86/64.  If so, I can take a shot at
> producing some javadoc language to reflect that, if it would be helpful.
>
>
>
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/jdk9-VarHandle-and-Fence-methods-tp12666p12680.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150822/e32fe71c/attachment.html>


More information about the Concurrency-interest mailing list