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

Boehm, Hans hans.boehm at hp.com
Mon Apr 19 19:14:03 EDT 2010

>From my perspective, it's important that

a) There is a usable subset of the language for which things are simple.  I think that currently consists of programs that (1) contain no data races, and (2) avoid a certain set of library calls that include lazySet and a handful of others.  Java guarantees sequential consistency for this subset, and the visibility issues don't arise.

b) There is an easy way to tell when you are leaving this subset.  This is currently getting a bit ugly.

For C++0x, the distinction (b) was made by requiring an explicit memory_order_X argument when you want to leave this subset.  I'm not sure what the best way is to make this distinction in Java.  As Doug points out, the pre-existence of lazySet and weakCompareAndSet complicate matters.  Possibly so does the desire to deal with array elements and the like; I'm not sure.

It seems to me that either new classes or a C++0x-like approach would require at least deprecation of lazySet and weakCompareAndSet.  That's likely to be to be a tough sell.

> From: Gregg Wonderly [mailto:gergg at cox.net] 

> What I thinking about, is the fact that I see the read vs 
> write accesses as a range of possibilities.  If you order 
> them from weaker on the outside to stronger on the inside as 
> something like
> 	non-volatile -> relaxed -> volatile:read
> and
> 	write:volatile <- relaxed <- non-volatile
> then you can imagine a "window" where particular guarantees 
> can hold.  Outside of that window, things are weaker.  For 
> any particular application, I am thinking that this window is 
> never completely open.
I'm not quite sure what you mean by "window" here.  One of the problems with the weaker ordering guarantees is that we don't seem to have a good handle on using weakly ordered operations (or data races on ordinary variables) in a way that is only locally visible.  Using weakly ordered operations anywhere seems to involve some danger of "contaminating" the whole program.  There do seem to be a few important idioms, like double-checked locking, that do localize the damage caused by weakly-ordered operations, but I don't know how to reason about that in general.

If I had to pick three possible ordering guarantees for atomic variables, I would add some flavor of acquire-release ordering, and keep only one of "non-volatile" and "relaxed".


More information about the Concurrency-interest mailing list