On 02/07/2014 09:44 PM, Brian Goetz wrote:
It's about time we brought atomic ops out of the shadows of Unsafe and
into the programming model proper! It was a good compromise ten years
ago to stuff these into Unsafe, but its time for these features to
grow up.
Specific to this proposal, I like how the VolatileXxx interface
approach allows us to add new fencing modes and/or atomic operations
should we discover that the initial set is deficient. I also like how
this potentially gives us a consistent story for volatile semantics on
array elements.
I can see a clean and straightforward implementation here at all the
required touch points: language spec, memory model, type system,
compiler, and VM runtime, and none of them require any special magic.
(Having spent some time exploring this design space myself, I think
the proposed surfacing is the least objectionable and most transparent
of the options that I've seen.)
Brian,
can you be a little more specific and provide the way
foo.volatile.compareAndSet is compiled with this example:
class Linked {
volatile Node head;
public void add(String element) {
for(;;) {
Node oldHead = head.volatile.get();
Node newNode = new Node(element, oldHead);
if (head.volatile.compareAndSet(oldHead, newNode)) {
return;
}
}
}
}
I will be very happy to see how you solve the different issues because
i've also spent some times thinking on how the .volatile syntax can be
implemented:
- what is the signature of the method compareAndSet, and how you
fight the generics erasure ?
- how do you remove the extra-level of indirection if head is a
VolatileXXX,
because accessing to the value is this.head.payload and not this.head ?
- what LinkedClass.class.getDeclaredField("head").getType() returns ?
regards,
Rémi
