[concurrency-interest] The Atomic*FieldUpdater situation

David M. Lloyd david.lloyd at redhat.com
Sun Jul 15 22:43:59 EDT 2012

On 07/15/2012 09:35 PM, David Holmes wrote:
> David,
> David M. Lloyd writes:
>> On 07/15/2012 06:14 AM, David Holmes wrote:
>>> 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.
>> Which is ridiculous because if a subclass "inherited" access to a normal
>> protected field on my class, I'd still be able to access it directly in
>> the base class... because fields aren't actually inherited.
> I think you are missing the point. Consider this:
> class Base {
>    protected volatile int x;
> }
> final class Secure extends Base { ... }
> Instances of Secure are only supposed to be used through their public API,
> as defined by Base and Secure. I hope you will agree that if I have an
> instance of Secure I shouldn't be able to arbitrarily mess with the value of
> x?
> But given
> class BackDoor extends Base {
>     static AtomicIntegerFieldUpdater<Base>  u = ... (Base.class, "x");
>     public static void setBaseX(Base target, int newX) {
>        u.set(target, newX);
>     }
> }
> without these protected access checks, BackDoor.setBaseX would allow you to
> update _any_ instance of Base.

I see your point, but in this case, wouldn't it be better to restrict 
updaters from being created on any class but their own, regardless of 
the access of the field?  In other words, we'd allow:

    static AtomicIntegerFieldUpdater<BackDoor> u = ... (Backdoor.class, 

but not:

    static AtomicIntegerFieldUpdater<Base> u = ... (Base.class, "x");

from BackDoor.

More information about the Concurrency-interest mailing list