[concurrency-interest] jdk9 VarHandle and Fence methods

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Sep 3 14:19:29 EDT 2015


Has anyone come up with the answer about ordering for tryLock, or have I 
missed it?

It seems that tryLock can fail without attempting a CAS, but what 
guarantees are really expected by the code users, and are they in line 
with this assumption.


Alex


On 22/08/2015 19:15, Vitaly Davidovich wrote:
>
> 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 
> <mailto: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
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> 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/20150903/6a4140e3/attachment.html>


More information about the Concurrency-interest mailing list