[concurrency-interest] Java atomics questions

Martin Buchholz martinrb at google.com
Wed Nov 20 15:24:31 EST 2013


Doug, I think the answers to Tom's questions belong in the JSR-133 Cookbook
(i.e. please add coverage for Unsafe operations and C++11 equivalents,
especially given that some implementers will be speaking C++11).
http://g.oswego.edu/dl/jmm/cookbook.html


On Wed, Nov 20, 2013 at 12:12 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/dfcbe7b1/attachment.html>


More information about the Concurrency-interest mailing list