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

David Holmes davidcholmes at aapt.net.au
Mon Apr 19 18:52:07 EDT 2010


I wrote:
> > If we had not already previously included some methods for
> > non-volatile ordering control (i.e., weakCompareAndSet, lazySet)
> > in AtomicX, I might be more sympathetic to creating classes
>
> weakCompareAndSet has nothing to do with non-volatile-ordering.

Which turns out to be wrong - sorry Doug. Although the primary function of
weakCAS is to allow spurious failures that are more amenable to a ll/sc
implementation, the package docs also define that it has weaker ordering
properties than strong-CAS.

David


> As for lazySet ... that had dropped off my radar. So I guess the genie is
> already out of the bottle.
>
> David
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea
> > Sent: Monday, 19 April 2010 11:38 PM
> > To: concurrency-interest at cs.oswego.edu
> > Subject: Re: [concurrency-interest] Extended access methods for Atomics
> > (and AQS)
> >
> >
> > On 04/15/10 08:49, David Holmes wrote:
> > >  I just don't think it is a good idea to have these
> > > obscure, rarely usable methods sitting along side the methods
> > that get used
> > > all the time.
> > >
> >
> > I never know what to do about the immorality accusations
> > whenever trying to improve the current state of affairs
> > about ordering control for atomics. But here's another pass
> > at laying out the motivation and current status:
> >
> > AtomicX already contains lazySet, which has a
> > naming bug (=> setInReleaseOrder) and specs in need
> > of improvement.  But AtomicX doesn't contain the
> > complementary weaker-than-volatile form of get
> > (=> getInRelaxedOrder) that is sometimes used with
> > it (as mentioned by Hans). My draft proposal fixes these,
> > and further regularizes API to accommodate a long-standing
> > RFE to add corresponding forms of CAS. The net result
> > has pretty much the same structure as C++0x atomics, which
> > is not only a good sanity check, but also in the future
> > (as C++0x atomics become supported by C++ compilers) will
> > improve confidence that JVMs written in C++, runtime-systems
> > supporting both C++ and Java, etc, work consistently.
> >
> > If we had not already previously included some methods for
> > non-volatile ordering control (i.e., weakCompareAndSet, lazySet)
> > in AtomicX, I might be more sympathetic to creating classes
> > AtomicXWithExtendOrderingControl. But as it stands, I don't think
> > the mere act of further fleshing them out and regularizing them
> > is a good reason to do so.
> >
> > I illustrated API with AtomicInteger, but as always,
> > the main practical need is for ordering methods applying
> > to the fields of other objects (including array elements).
> > These are more typical/desirable because without them:
> > (1) if you need ordering control and must create
> > another Atomic object to obtain it, then you have traded one
> > problem for two problems, because you must now figure out
> > how to correctly maintain reference to that Atomic;
> > (2) Creating AtomicXs (especially cases like arrays of
> > AtomicIntegers as opposed to arrays of ints supporting ordering
> > control) can (and usually does) lead to so much space and
> > indirection bloat that you may be better off just running slow
> > lock-based code (assuming you can figure out how to use locks in
> > such cases, which is not always possible).
> >
> > If Java/JVMs supported some way to force object-inlining
> > so that a (suitably declared) AtomicInteger field of
> > another object could be embedded as an int field but
> > accessed via atomics, there would be no need for alternatives.
> > But I don't think this will happen anytime soon.
> >
> > Short of such major language/JVM changes, one way of handling
> > these cases is with Fences, that separate out the ordering
> > control from the reads and writes (although unfortunately not CAS).
> > This way, programmers just do the field accesses but surround
> > them with acquire-, release-, or volatile- style fence method
> > calls (which would normally be instrinsified and inlined).
> >
> > But many people objected to this approach: Some on
> > morality grounds, others on usability grounds, and others
> > because the specs under this form of separation are very
> > hard to nail down and incorporate into JMM/JLS.
> > It seems that most people agree that it would be better
> > all around to support and spec ordered accesses
> > than separating accesses plus orderings.
> >
> > One way to do this is to extend AtomicXFieldUpdaters.
> > This is not a very nice choice. Java, Java bytes codes, and
> > JVMs were not originally designed to support "l-value"
> > operations on fields of objects beyond simple read/write.
> > The only path to do so is via the defacto-standard "Unsafe"
> > APIs that bypass all of the normal apparatus (including
> > verification and safety checks) to perform ordered/atomic
> > accesses at particular offsets of objects/arrays. So if
> > you want to export these methods in public APIs, you must surround
> > them with Java-level dynamic type- and accessibility-
> > checking (and further, restrict use to fields marked as
> > volatile, which doesn't work for arrays).
> >
> > Which brings us to the same kind of cure-worse-than-disease
> > problem seen with the alternative of using standalone Atomics:
> > On most platforms, the overhead of performing, say
> > updater.lazySet(x) (aka setInReleaseOrder(x)) is greater than
> > any savings you get from avoiding underlying hardware fences
> > if you simply did a direct volatile write. (Worse, in some
> > cases the checks may themselves entail stronger fences.)
> > Even in their current forms (without the above minor extensions)
> > no one is tempted to use these methods. (Google code search
> > does not find even one  application-level usage of
> > AtomicIntegerFieldupdater.lazySet.) Instead, as
> > is occasionally posted on this list, people developing carefully
> > weakly ordered code have learned to use Unsafe directly,
> > avoiding the overhead. Although at the price of having no
> > language-level static checking and containing code that does
> > not work on systems with security managers.
> >
> > My hope has been that there might be some way to reduce
> > this dynamic checking overhead in updaters, so that people
> > can stop using Unsafe directly. But after some further exploration,
> > I'm less optimistic about the prospects -- even with JSR292-based
> > support, the cases in which you can trade improved updater
> > creation-time checks for fewer or faster dynamic per-update
> > checks don't seem to cover many usages.
> >
> > Which leaves me not having a really good plan at the moment.
> > This is a problem that is not going to go away all by itself,
> > so concrete suggestions would be welcome.
> >
> > -Doug
> >
> > _______________________________________________
> > 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



More information about the Concurrency-interest mailing list