[concurrency-interest] The Atomic*FieldUpdater situation

Doug Lea dl at cs.oswego.edu
Sat Jul 14 14:18:04 EDT 2012


On 07/14/12 14:01, David M. Lloyd wrote:
> What is the purpose of the access-time access check in the atomic field updater
> classes?

It is because there is no way to check that you haven't handed
your Updater to some untrusted party, so the caller context must
be checked on each use. I agree it is very annoying and slow.

>
> I mean I'm using field updaters in the first place because I can't afford to
> have a jillion Atomic* objects floating around; obviously performance is
> critical here. And to add to this problem, you can't even rely on using Unsafe,
> even though it's becoming more and more prevalent in JDKs, as some platforms may
> not have atomic 64-bit operations, and there's no way I can see to test for that
> other than relying on the AtomicLong implementation to be similar to OpenJDK's.
>

We stopped using Updaters entirely inside j.u.c as of JDK7 and
use straight Unsafe calls without even checking for 64bit atomics.
Which means that we are relying on every JDK7+ VM to somehow
implement the 64bit version of Unsafe CAS. So if you are targeting JDK7+
only, you might take some comfort that if j.u.c cannot run, then it
probably doesn't matter if your code runs, and so don't worry about
the checks :-)

> Is there any recourse to solve this issue?

Maybe someday. Remi Forax has mentioned a few times that JDK8 method
handle and invokeDynamic support should make this or some variant
API a lot faster. We'll see...

-Doug




More information about the Concurrency-interest mailing list