[concurrency-interest] Java atomics questions

Doug Lea dl at cs.oswego.edu
Wed Nov 20 18:52:50 EST 2013


On 11/20/2013 06:31 PM, Boehm, Hans wrote:
> I would assume that putOrderedObject corresponds to lazySet and C11/C++11
> memory_order_release (only the last of which has a precise definition).  Which
> means it kind of, sort of has a StoreStore fence BEFORE it, but that’s in
> general stronger than its definition.

Yes, implementations of putOrderedX use the equivalent of a C++
memory_order_release. Without a JMM overhaul, we cannot give it
as precise specs as it deserves.

>
> putObjectVolatile presumably corresponds to C/C++ memory_order_seq_cst, and has
> a trailing fence on x86.  (On Power and ARM, things are much more complicated,
> and that’s not IBM’s implementation recommendation.  See
> http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html.)
>
> Other than that, I agree with what follows.

Me too.

-Doug


>
> Hans
>
> *From:*concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *Nathan Reynolds
> *Sent:* Wednesday, November 20, 2013 12:39 PM
> *To:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] Java atomics questions
>
> I am not the expert here but I would like to take a stab at it... and be corrected.
>
> I think putObjectVolatile() has a full memory fence after it.  Whereas,
> putOrderedObject() has a store-store memory fence after it.  On x86, the
> store-store memory fence doesn't emit an instruction since the x86 memory model
> already forces stores to proceed in order.  However, the memory fence prevents
> JIT from rearranging the store instructions.
>
> On x86, atomic_fetch_add() ideally would compile into a single instruction: lock
> xadd.  This is much stronger guarantee than doing a += on a Java volatile.  +=
> would compile to the following...
>
> tmp = atomic_load(&i);
> atomic_store(&i, tmp + 666);
>
>  > Currently we just add the volatile keyword to the Objective-C field
> declaration, which doesn't support Java's definition.
>
> This is going to come back to bite you.  I highly recommend supporting Java's
> definition.  This simply means all accesses to the Java volatile variables must
> be done with atomic_load and atomic_store.
>
> -Nathan
>
> On 11/20/2013 1:12 PM, Tom Ball wrote:
>
>     I'm a member of the J2ObjC <https://code.google.com/p/j2objc/> project, an
>     open-source Jave to Objective-C transpiler. The java.util.concurrent
>     packages have recently been added to its JRE emulation library, but we have
>     some unanswered questions.
>
>     The sun.misc.Unsafe class is used by java.util.concurrent.atomic; we have a
>     partial implementation based on Android's version. I'm fuzzy on its
>     distinction between "ordered" and "volatile" field access, though. I assumed
>     that ordered means "requires a memory barrier", while volatile doesn't. Is
>     that correct? Here is our putObjectVolatile()
>     <https://code.google.com/p/j2objc/source/browse/jre_emul/Classes/sun/misc/Unsafe.java#201> and
>     putOrderedObject()
>     <https://code.google.com/p/j2objc/source/browse/jre_emul/Classes/sun/misc/Unsafe.java#287> with
>     that assumption. Look reasonable? (The native comments hold Objective-C, but
>     in this case it's vanilla C.)
>
>     Also, is anyone familiar with the C11 optional atomic operations
>     <http://en.cppreference.com/w/c/atomic> support? Clang has the necessary
>     atomic intrinsic functions to support it and generates reasonably looking
>     code, so we're hoping to fix translation of Java volatile fields with it.
>     Currently we just add the volatile keyword to the Objective-C field
>     declaration, which doesn't support Java's definition. Our thoughts for a
>     better translation look something like:
>
>        volatile int i;
>
>     ...
>
>        i = 42;
>
>        i += 666;
>
>     becomes:
>
>        atomic_int i;
>
>     ...
>
>        atomic_store(&i, 42);
>
>        atomic_fetch_add(&i, 666);
>
>     Is that a reasonable approximation of Java volatile field semantics in C11,
>     or is there a better approach?
>
>     Tom
>
>     P.S. Forgive me my concurrency fumbling -- I realize compiler writers should
>     leave such design to the experts. :-)
>
>
>
>
>     _______________________________________________
>
>     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
>





More information about the Concurrency-interest mailing list