[concurrency-interest] Java atomics questions

Vitaly Davidovich vitalyd at gmail.com
Wed Nov 20 15:32:14 EST 2013

Sorry, hit send by accident ...

Ordered write just orders stores; on x86/64 this equates to just compiler
barrier - no mem fence.  Volatile stores on this arch emit full machine
fence instructions (this used to be mfence, now a lock add r/esp 0 nop that
provides same fence) + corresponding compiler fence, of course.

Sent from my phone
On Nov 20, 2013 3:28 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Hi Tom,
> Google for Doug Lea's compiler cookbook - it should have the JMM details
> for you.
> Volatile writes entail sequential consistency (with corresponding read) so
> it's a full fence.  Ordered write
> Sent from my phone
> On Nov 20, 2013 3:18 PM, "Tom Ball" <tball at google.com> 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
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131120/303b901a/attachment-0001.html>

More information about the Concurrency-interest mailing list