[concurrency-interest] The Atomic*FieldUpdater situation

Stanimir Simeonoff stanimir at riflexo.com
Sat Jul 14 16:01:59 EDT 2012

On Sat, Jul 14, 2012 at 9:18 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> 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.

But how that's a problem - you create, you hand it over, exactly as adding
an extra method public. I can't even see how that can be an argument. The
checks should be during creation only, not during  usage time - the calling
class is trivial to infer. I wanted to voice that for very long time and
used to always used to forget.
Alternatively the SecurityManager should be checked and if not present a
non-checking sub-class shall be returned. W/o SecurityManager it's possible
to create modifiable java.lang.String not even touching
Field/Method.setAccessible or Unsafe.
That option doesn't require API changes. Since there would be a single
subclass only instantiated in the JVM there would be no performance loss
from multi-site invocations.

Exactly that reason [pointless checks] has forced quite a few developers
(and libs) going straight to sun.misc.Unsafe... or extend the AtomicXXX
instead java.lang.Object (that at least is portable).

Kind Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120714/0a32d507/attachment.html>

More information about the Concurrency-interest mailing list