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

David M. Lloyd david.lloyd at redhat.com
Tue Apr 20 15:24:35 EDT 2010


Was it not established that using a simple Field.set() is as effective as 
unsafe.putObjectVolatile() in the case of final fields?

On 04/20/2010 12:45 PM, Michael Spiegel wrote:
> 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
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-- 
- DML ☍


More information about the Concurrency-interest mailing list