JEP 193: Enhanced Volatiles

[David M. Lloyd]

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.

Other random thought, the proposed .volatile syntax possibilities are a 
little funny (even by the standards of the base strangeness of the 
proposed syntax):

   // one of these I guess?
   int[] foo = ...;
   int x = foo[0].volatile.compareAndSet(10, 15); // this one, I suppose?
   int x = foo.volatile[0].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.

-- 
- DML