JEP 193: Enhanced Volatiles
David M. Lloyd
david.lloyd at redhat.com
Wed Mar 5 23:05:13 UTC 2014
On 03/05/2014 02:37 PM, David M. Lloyd wrote:
> On 03/03/2014 04:25 PM, Brian Goetz wrote:
>>> Posted: http://openjdk.java.net/jeps/193
>> Some follow-up thoughts on teasing apart the issues covered by this JEP.
>> There are three main layers of questions to answer:
>> 1. How do we surface the various pieces of this into the programming
>> model? This includes language syntax (e.g.,
>> x.volatile.compareAndSet()), library surface (e.g., the fictitious and
>> not-terribly-satisfying VolatileInt interface), and relevant
>> restrictions (e.g., can we do volatile operations on non-volatile fields
>> or array elements?)
> Also, relatedly, how far is this taken? It is easy to imagine
> operations of this sort on reference fields and fields of all 8
> primitive types, as well as arrays of all 8 primitive types, and object
> arrays (which would of course cover all arrays-of-arrays as well).
> Following the interface idea, you would need (at a maximum) one
> interface type for each primitive type and one interface type for
> Objects. Arrays should be able to reuse the same interface type since
> array element types are constrained to the same set of possible types as
> fields (though without an actual volatile qualifier of course).
> So 9 interface types at maximum. At minimum, just having interfaces for
> ints, longs, and Objects would match what is presently defined in
> j.u.c.atomic, so 3 seems to be the low end.
> Personally I think it would be nicest to support all 8, but I expect
> there were probably good reasons (I'm guessing relating to false
> sharing) that we don't have AtomicBooleanArrays and so forth.
This should be "all 8 primitive types".
> Other random thought, the proposed .volatile syntax possibilities are a
> little funny (even by the standards of the base strangeness of the
> proposed syntax):
This should have been "possibilities *for arrays* are a little funny"...
Guess I shouldn't bother sending emails with kids about.
> // one of these I guess?
> int foo = ...;
> int x = foo.volatile.compareAndSet(10, 15); // this one, I suppose?
> int x = foo.volatile.compareAndSet(10, 15);
> If .volatile is treated as a postfix unary operator which operates on
> the left-hand term (what precedence I wonder? probably pretty high),
> then the first option makes the most sense and aligns well with
> "[objectexpression.]foo.volatile..." where "foo" is a field.
More information about the core-libs-dev