JEP 193: Enhanced Volatiles (original) (raw)

Brian Goetz brian.goetz at oracle.com
Wed Mar 5 16:44:22 UTC 2014

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

More information about the core-libs-dev mailing list