[concurrency-interest] jdk9 VarHandle and Fence methods

Vitaly Davidovich vitalyd at gmail.com
Thu Sep 3 23:09:42 EDT 2015


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
> <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
> <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/20150903/de791758/attachment.html>


More information about the Concurrency-interest mailing list