JEP 193: Enhanced Volatiles

[David M. Lloyd]

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[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