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

Michael Spiegel michael.m.spiegel at gmail.com
Tue Apr 20 13:45:26 EDT 2010


I use unsafe.putObjectVolatile() in my implementation of
ConcurrentSkipTreeSet that is backed by an underlying
ConcurrentSkipTreeMap.  It is identical to the trick that Doug uses in
j.u.c.ConcurrentSkipListSet.

On Tue, Apr 20, 2010 at 1:06 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> 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
>
> _______________________________________________
> 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