[concurrency-interest] jdk9 VarHandle and Fence methods

David Holmes davidcholmes at aapt.net.au
Thu Sep 3 23:32:09 EDT 2015


I don’t agree that is a general use-case. You can always postulate a need for a happens-before edge between two things. I don’t think it is reasonable to expect one on a failing tryLock. Any shared state will need to be protected by a lock or else volatile – and those should be what establishes the HB edges in my opinion.

 

David

 

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Vitaly Davidovich
Sent: Friday, September 4, 2015 1:10 PM
To: dholmes at ieee.org
Cc: thurston; concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] jdk9 VarHandle and Fence methods

 

If thread A releases a lock and threads B and C tryLock it, with one succeeding, the failing thread may want to do something else but wants a happens-before edge with the lock release - that's the general use case.  As a simple example, consider two threads tryLock'ing to acquire the exclusive right to close a socket and then perform some additional actions that require ordering of actions done by the releasing thread.  The thread failing to acquire the lock will skip closing the socket but will proceed to do some work that requires happens-before edge.  This is typically done using CAS, with one thread successfully flipping the state, and the others just skip that action that's guarded by the CAS, but can proceed with doing subsequent work.  In other words, one may want to piggyback on the unlock/tryLock to provide the ordering rather than introducing additional dedicated state for this.

sent from my phone

On Sep 3, 2015 7:26 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:

j.u.c also adopts the same principle:

 

Actions prior to "releasing" synchronizer methods such as Lock.unlock, Semaphore.release, and CountDownLatch.countDown happen-before actions subsequent to a successful "acquiring" method such as Lock.lock, Semaphore.acquire, Condition.await, and CountDownLatch.await on the same synchronizer object in another thread.

 

Note the use of “successful” which already indicates tryLock is not included here.

 

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:48 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

 

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] 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> 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







_______________________________________________
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/20150904/1d556baf/attachment-0001.html>


More information about the Concurrency-interest mailing list