[concurrency-interest] Extended access methods for Atomics (and AQS)
hans.boehm at hp.com
Fri Apr 16 18:56:16 EDT 2010
> From: Doug Lea
> 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.
I'd certainly also be open to other ideas, but I'm not sure that "release"
is so bad here. It does seem to have slightly different meanings in
different contexts. But my impression is that they are all close enough
to convey the general idea.
> > 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
> 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.
I'm sorry. I wasn't precise enough here. This indeed matters
only for "relaxed" order, and I should have stated that explicitly.
This is really a question about relaxed operations, and whether
we want the naming or description to refer to ordinary variable
accesses. But I think it remains an important question if we want
to support "relaxed" operations.
> > 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:
Looks promising to me.
I guess the intent would be that I could use a getInRelaxedOrder() to read
the pseudo-final field, and the compiler would have to preserve "deep accesses"
through that? That may well work, based on semantics like those in the
fences draft. Partially contradicting what I said in my last message,
this may have the large advantage over the fence-based versions that it
seems to have minimal impact on anything that doesn't explicitly
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest