JEP 193: Enhanced Volatiles

[Brian Goetz]

(This is already-traveled ground.)

The ++/--/+= trick is cute as a shorthand, but without a means of 
expressing a full-blown CAS, falls short of the goal of "integrate 
atomic read-modify-write operations into the programming model."  IF the 
latter problem was addressed, we might consider redefining ++ and 
friends to be shorthand for an RMW operation, and extending that to be 
atomic if applied on volatiles.  But only if we can get all the way there.

The "new operator" addresses the above-mentioned hole (though will 
confuse the hell out of the 99.99% of users that will never use it, but 
who will still see it on the table of operators in their CS 101 
textbook), but runs up against of a different goal; expressing not only 
atomic operations, but all the possible fencing modes.  There's no way 
we're going to invent a new syntax for each fencing mode, and we don't 
even know that we will never add new fencing modes.  One of the goals 
here is to align with JMM9, which has a goal of aligning with the 
recently minted C++ MM (so that we can have a coherent MM across Java 
and native code.)  Though, if we were willing to separate fencing from 
access, this idea might re-emerge as viable.



> Reading about ideas to integrate atomic operations into the language, I
> was asking myself which of these operations I was using most frequently
> in my own code (currently by means of
> java.util.concurrent.atomic.AtomicXXX variables) and how they could be
> made more convenient with built-in support.
> Here's my top 5 list:
>
> 1. AtomicReference.compareAndSet(T expect,T update). In almost all of
> the usecases, "expect" was null.
>
> 2. AtomicBoolean.compareAndSet(boolean expect, boolean update. In almost
> all of the usecases, "expect" was false.
>
> 3. AtomicReference.getAndSet(T update).
>
> 4. AtomicInteger.getAndIncrement().
>
> 5. AtomicInteger.getAndDecrement().
>
> Now, 4. and 5. would be the easiest to solve: Make postfix "++" and "--"
> implicitly atomic if used on volatile variables. I know that this would
> require a change of the JLS, but on the other hand, the precise meaning
> of "volatile" has been changed once before, so would this be a showstopper?
>
> For cases 1. and 2. one could think of a new operator "lhs ?= rhs" with
> the meaning
> "Assign the rhs to the lhs only if lhs is currently null. Return true if
> the assignment took place (Alternatively, return rhs if the assignment
> took place. Would be more consistent with other assignment operators and
> convey the same amount of information as a boolean value).  Make the
> operation atomic if lhs is a volatile variable".
>
> For case 3. one could devise an operator "lhs := rhs" with the meaning
> "Assign the rhs to the lhs and return the previous content of the lhs.
> Make the operation atomic if lhs is a volatile variable".
>
> Note that the new operators would have consistent meaning even if used
> with non-volatile variables (even though they wouldn't provide exciting
> new possibilities)
>