[concurrency-interest] Java atomics questions
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).
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;
> 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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest