[concurrency-interest] Java atomics questions

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

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/0c7a11e5/attachment.html>

More information about the Concurrency-interest mailing list