[concurrency-interest] The Atomic*FieldUpdater situation

David Holmes davidcholmes at aapt.net.au
Sun Jul 15 07:14:27 EDT 2012

David M. Lloyd writes:
> What is the purpose of the access-time access check in the atomic field
> updater classes?

Do you mean the ensureProtectedAccess check?

This is to ensure that you can't get an updater for a protected inherited
field in SubtypeA, then use that updater to access/modify the field in an
instance of SubtypeB.

> If I construct an atomic field updater, to me, this should be exactly
> equivalent to having an accessible=true Field instance.  If I want to
> manage the visibility of that instance, I will restrict access to the
> updater itself.
> The problem, as I am sure you are all well aware, is that when the
> updater classes are used on an object instance which is subclassed, even
> if the field being updated, the field updater, and the method calling
> into the field updater all exist on the base class and are private, an
> expensive access check has to occur.

Now you've lost me. Which access check is this? All of the methods do:

if (obj == null || obj.getClass() != tclass || cclass != null)

where fullCheck is:

        private void fullCheck(T obj) {
            if (!tclass.isInstance(obj))
                throw new ClassCastException();
            if (cclass != null)

and ensureProtectedAccess is:

       private void ensureProtectedAccess(T obj) {
            if (cclass.isInstance(obj)) {
            throw new RuntimeException(
                new IllegalAccessException("Class " +
                    cclass.getName() +
                    " can not access a protected member of class " +
                    tclass.getName() +
                    " using an instance of " +

So if everything is in the same class we don't do any additional checks.


> Even when the class is final, the access check is still expensive
> relative to the operation itself!
> 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.
> Is there any recourse to solve this issue?
> --
> - DML
> _______________________________________________
> 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