[concurrency-interest] Extended access methods for Atomics (and AQS)

Doug Lea dl at cs.oswego.edu
Tue Apr 20 07:17:41 EDT 2010

On 04/19/10 19:14, Boehm, Hans wrote:
>> From my perspective, it's important that
> a) There is a usable subset of the language for which things are simple.

> b) There is an easy way to tell when you are leaving this subset.

The initial idea was that this subset need not include AtomicX.
But I guess as AtomicX becomes more "ordinary", some people
are less comfortable with this? Perhaps AtomicXFieldUpdater is still
exotic and ugly enough to qualify? If not, calls to Unsafe
definitely do, since you are no longer even coding in "Java",
but instead coding in JVMese. (Unsafe has never been standardized
as part of the language or JVM).

Most of the small community of users of weak ordering methods
would not object to making it arbitrarily ugly to use them.
I suspect that they would be OK with continuing to use
Unsafe calls if we could solve the problems
of standardizing them (as part of JVM, not Java spec?) and
finding some path to allow such code to run on systems with
security managers. (Ideas welcome.)

The main exceptions to this are some of the less esoteric
usages we discussed with Fences, such as safe publication
of fields that act as final but cannot be declared as final
because their values are not set inside constructors
(for example in dependency injection frameworks).


More information about the Concurrency-interest mailing list