[concurrency-interest] Java atomics questions

Oleksandr Otenko oleksandr.otenko at oracle.com
Wed Nov 20 18:43:39 EST 2013


You want the semantics of "write(y) implies write(x)" in order for 
"read(y) implies read(x)". So you will want a store-store between x and 
y, not after y.

Alex

On 20/11/2013 20:39, Nathan Reynolds wrote:
> 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
>> 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/20131120/8266c4d8/attachment.html>


More information about the Concurrency-interest mailing list