[concurrency-interest] jdk9 VarHandle and Fence methods

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Sep 3 18:17:49 EDT 2015


You should at least see everything preceding the lock acquire - since 
you see the lock acquired - and therefore everything preceding the lock 
release.

Alex


On 03/09/2015 21:57, David Holmes wrote:
>
> tryLock seems a non-issue to me. If you acquire a lock you are 
> guaranteed to see all changes made by previous owners of the lock. If 
> you fail to acquire the lock then … you should not be expecting anything.
>
> David
>
> *From:*concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of 
> *Oleksandr Otenko
> *Sent:* Friday, September 4, 2015 4:19 AM
> *To:* Vitaly Davidovich; thurston
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] jdk9 VarHandle and Fence methods
>
> 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
>     <mailto: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/1382fe02/attachment.html>


More information about the Concurrency-interest mailing list