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

Doug Lea dl at cs.oswego.edu
Fri Apr 16 08:17:49 EDT 2010


On 04/15/10 20:46, Boehm, Hans wrote:
> Even if we don't immediately give these any sort of formal semantics, it would be good to be clearer on what these are intended to mean.  That also affects the naming.  I think the semantics are currently unclear along a few dimensions:
>
> 1) Do they implicitly include fences?  I think we agree that the answer is no, i.e.
>
> x1 = 1;
> a.setInStoreOrder(1);
> x2 = 2;
>
> does not guarantee that the assignments to x1 and x2 become visible in order.  If this is correct, and I strongly believe it should be, I think we should avoid mentioning "fence" in the name.
>

Good point. Even "setInStoreOrder" is not crystal clear -- we do
not want to imply orderings wrt subsequent stores (although as
a quality of implementation matter, they will still be issued
"promptly"). Perhaps "setInReleaseOrder" is clearer even though
it has the different problem of using the overloaded term "release"
(and thus leads to unrelated confusion). Further suggestions would be welcome.


> 2) Do they obey "cache coherency" rules, i.e. do the operations on a single variable appear totally ordered?  In particular, if we have x initially zero and:
>
> Thread 1:
> x = 1;
> x = 2;
>
> Thread 2:
> r1 = x;
> r2 = x;
>
> Can we have r2<  r1?  Ordinary Java variables intentionally allow this.  When this was discussed in the context of C++0x atomic<T>, the feeling was that this was too weakly ordered to be useful.  I tent to agree.  (This does affect implementation cost, due both to the "reads kill" issue, and because a few architectures, notably Itanium, allow the unexpected behavior for ordinary loads.)  If this is disallowed, we probably shouldn't name this to suggest that it's equivalent to ordinary memory operations.  And I suspect it should be disallowed.
>

I'm not sure this requires any special attention. Recasting the example
with the actual method calls would by default use volatile/acquiring
reads:

T1:
x.setInStoreOrder(1);
x.setInStoreOrder(2);

T2:
r1 = x.get(); // == volatile read
r2 = x.get();

You'd need to explicitly use getInRelaxedOrder() instead of get()
to open yourself up to surprising results.


> 3) Can I really use "StoreOrder" variants to emulate "final"?

Well, the disclaimer that it is like final except that you can reset
it makes the ties to the JMM/JLS final-field specs metaphorical at best.
We still do want to convey that the method can be used to these effects
in typical cases. But the specs themselves will be messy. The state
we left Fences specs  seem close to being usable here if you bind the
accesses with the fences in the rules:
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html

-Doug





More information about the Concurrency-interest mailing list