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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 20 13:06:18 EDT 2010


I think it would be helpful to hear directly from more of the folks who use
the Unsafe stuff currently.

Is there anyone (besides Doug:) who can pipe up?

On Tue, Apr 20, 2010 at 9:19 AM, Gregg Wonderly wrote:

> 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
>>>
>>
>>  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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100420/77525996/attachment.html>


More information about the Concurrency-interest mailing list