[concurrency-interest] The Atomic*FieldUpdater situation

Jason T. Greene jason.greene at redhat.com
Fri Jul 20 14:42:34 EDT 2012

On 7/15/12 9:52 PM, David Holmes wrote:
> David M. Lloyd writes:
>> On 07/15/2012 09:35 PM, David Holmes wrote:
>>> 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,
>> "x");
>> but not:
>>      static AtomicIntegerFieldUpdater<Base> u = ... (Base.class, "x");
>> from BackDoor.
> In hindsight, in the context of the current discussion, it may have been
> better to restrict things this way to allow access checks to be elided. But
> that has to be weighed up against use-cases where it is an inherited field
> that needs the atomic update.

I still don't get why this needs to operate any differently than 
reflection. With reflection I can do the same thing in Backdoor. I just 
make a call to setAccessible, and a security check is done with a 
security manager. Why can't the updaters do the same?

Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list