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
