[concurrency-interest] jdk9 VarHandle and Fence methods

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri Sep 4 05:12:05 EDT 2015


At least you will have HB edges that preclude certain ordering.

I may still use volatiles to share my data, but use a failing tryLock to 
prove it shall be visible to anyone who releases the lock - because 
that's a reasonable thing to assume that the volatile reads following 
the release will be ordered strictly after the failing tryLock in the 
total synchronization order. Even though there is no synchronizes-with 
edge between the lock release and the failing tryLock, tryLock cannot be 
placed after the lock release, and, therefore, all subsequent volatile 
reads are also after the volatile writes preceding the failing tryLock, 
thus they are bound to synchronize-with. This, you see, still requires 
the specification how a failing tryLock is ordered with respect to 
acquires and releases. The fact that it is not specified is exactly the 
reason to bring this up.

Alex

On 04/09/2015 04:32, David Holmes wrote:
>
> 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 
> <mailto: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> 
> [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 8:48 AM
> *To:* dholmes at ieee.org <mailto:dholmes at ieee.org>; '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
>
> 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>
>     [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 <mailto:dholmes at ieee.org>; '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
>
>     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
>
>
>
> _______________________________________________
> 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/d8d0d32a/attachment-0001.html>


More information about the Concurrency-interest mailing list