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

Doug Lea dl at cs.oswego.edu
Thu Apr 15 07:57:11 EDT 2010


On 04/14/10 19:49, David Holmes wrote:

> I think "InStoreorder" and "InRelaxedOrder" could easily be misunderstood as
> relating to "total store ordering", or "relaxed memory models" or any
> particular architecural memory model that uses that kind of terminology.
>

How about "setInStoreFencedOrder" (borrowing from one
version of our Fences API terminology)?  Note that this method
is the same as existing "lazySet", which we adopted in part because
people wanted an obscure name, but it is so obscure that people
don't even try to understand it. (Mainly because the "lazy" in lazySet
is deceptive. As a quality of implementation matter, store-fenced
writes should be issued as soon as eligible, and are in hotspot
and other JVMs. The sense of laziness is only wrt Sequential
Consistency, which is a connection most people don't make.
Also, as Hans has pointed out a few times, the specs for this
method really ought to be spelled out along the lines of what we
did for Fences.storeFence (aka orderWrites).)

I don't see the problem with using the term "relaxed"
to mean "non-volatile, non-final", as introduced by the C++0x folks.
You need some term to denote this (just "non-volatile" is not quite
accurate), so might as well observe precedent?

> I guess this is somewhat better than Fences in that the semantics of the
> methods are easier to understand. But these are still methods that the vast
> majority of programmers won't know when it is valid to use them. They will
> only discover that they seem faster and so use them regardless :( Can we not
> "hide" them a bit better

Well, the current options are maximally hidden and maximally ugly.
As people have already pointed out, those who do know when to
use them currently need to access them via Unsafe. Which, as always,
bothers me. People increasingly take this path, making it even
harder to get constructions right, and making it impossible to run their
code on platforms with security managers that prevent Unsafe access.
Would you rather see this practice continue?

While I am at it ...

The AtomicInteger draft contains store- and load- fenced
forms of CAS that represent the only "new" functionality
introduced here:
   boolean compareAndSetInStoreOrder(int e, int v);
   int compareAndSetAndGet(int e, int v);
These provide orderings for CAS matching
the ones for get and set. Some people have been
asking for them for a long time (especially for Azul and
Itanium, also probably worthwhile on ARM and POWER).
They are not at all commonly used, and are always
implementable using plain CAS. But defining them makes
available for special intrinsification on some platforms.
This is a similar story as we have already for
weakCompareAndSet, which I think these days is only
specially intrinsified on Azul's JVM.

-Doug


More information about the Concurrency-interest mailing list