[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

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