[concurrency-interest] jdk9 VarHandle and Fence methods

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Sep 3 18:48:09 EDT 2015


Sure, lock acquires and releases in JMM don't guarantee ordering until 
the lock is acquired. But also they don't have a tryLock in JMM - as it 
really concerns the synchronized, doesn't it.

Alex

On 03/09/2015 23:34, David Holmes wrote:
>
> Not sure what “everything” is. If Thread A releases the lock and 
> thread B acquires it, then B sees everything that happened in A before 
> the release. If thread C now does a tryLock and sees the lock is 
> already owned you are suggesting it should see what thread B sees 
> because if it had acquired the lock then that would be the case. But 
> it didn’t acquire it, it only sees that it is already acquired by 
> another thread. So I don’t see there is any transitive relationship 
> that has to be applied here. Implementation wise it is likely but in 
> terms of the model I think expectations and requirements should be nil.
>
> 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 8:18 AM
> *To:* dholmes at ieee.org; 'Vitaly Davidovich'; 'thurston'
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] jdk9 VarHandle and Fence methods
>
> 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>
>     [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
>     <mailto: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/6403b0dc/attachment.html>


More information about the Concurrency-interest mailing list