[concurrency-interest] jdk9 VarHandle and Fence methods

Vitaly Davidovich vitalyd at gmail.com
Sat Aug 22 14:17:32 EDT 2015


As for higher order variants, I'd vote to keep them out unless they can be
done more cheaply by virtue of being backed by some intrinsics.  Otherwise,
anyone can build them on top of the lower level functionality.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150822/59c546fb/attachment.html>


More information about the Concurrency-interest mailing list