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

David Holmes davidcholmes at aapt.net.au
Mon Apr 19 18:23:11 EDT 2010


> 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.

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



More information about the Concurrency-interest mailing list