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

Gregg Wonderly gregg at cytetech.com
Tue Apr 20 12:19:37 EDT 2010

Boehm, Hans wrote:
>>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.

Data races seem to often appear as people try to make use of more "cores" by 
creating threading and associated localized processing which can result in 
publication of values between threads which then has to be mediated for 
visibility guarantees.  This is the specific problem that I seem to read about 
and see people having problems with over and over.

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

When there is more than one thread running, you have this problem.  For Java 
client programs, you have the EDT and the applications main thread that are 
separate.  If you then drive everything from EDT event dispatches, that can work 
for applications without networking or other background activity.  As soon as 
you add another thread, the possibilities of data races soar.

> 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.

Only publication of arrays creates the problem in a multi-threaded environment. 
  A single thread has no problems with an array.  Multiple threads are going to 
be a given in any Java application it seems to me, so I'm not sure how any Java 
application can have sequential consistency without some degree of 
"synchronized" or "volatile" for any mutable values.

It is all of the overhead and problems associated with the "delay" through such 
"operations" that we are talking about addressing I thought.

> 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.

Correctness of software is an important detail.  Being able to somehow 
understand and prove this is vital as we decide more and more on making software 
systems a part of things we depend on for continuous duty.

Gregg Wonderly

>> 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".
> Hans
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list