[concurrency-interest] jdk9 VarHandle and Fence methods

David Holmes davidcholmes at aapt.net.au
Thu Sep 3 19:26:45 EDT 2015


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-metho
ds-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/87af338e/attachment-0001.html>


More information about the Concurrency-interest mailing list