(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)
