atom feed19 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] The Atomic...
FromSent OnAttachments
David M. LloydJul 14, 2012 11:01 am 
Doug LeaJul 14, 2012 11:17 am 
Stanimir SimeonoffJul 14, 2012 1:01 pm 
√iktor ҠlangJul 14, 2012 1:16 pm 
Rémi ForaxJul 14, 2012 2:20 pm 
Stanimir SimeonoffJul 14, 2012 2:58 pm 
Rémi ForaxJul 14, 2012 3:44 pm 
Doug LeaJul 15, 2012 3:37 am 
David HolmesJul 15, 2012 4:14 am 
√iktor ҠlangJul 15, 2012 8:22 am 
David M. LloydJul 15, 2012 9:19 am 
Jed Wesley-SmithJul 15, 2012 7:31 pm 
David HolmesJul 15, 2012 7:35 pm 
David M. LloydJul 15, 2012 7:43 pm 
David HolmesJul 15, 2012 7:52 pm 
Jason T. GreeneJul 20, 2012 11:42 am 
David HolmesJul 20, 2012 6:34 pm 
David M. LloydJul 22, 2012 1:47 pm 
Doug LeaJul 23, 2012 3:44 am 
Subject:Re: [concurrency-interest] The Atomic*FieldUpdater situation
From:David Holmes (
Date:Jul 20, 2012 6:34:08 pm

Hi Jason,

Jason T. Greene writes: 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?

Because it is not reflection. Reflection is (in part) a mechanism to step outside the language to do things the language wouldn't normally permit. The atomic updaters are intended as an extension to normal field operations (putfield/getfield) and so they enforce language level access controls.