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:Stanimir Simeonoff (
Date:Jul 14, 2012 1:01:55 pm

On Sat, Jul 14, 2012 at 9:18 PM, Doug Lea <> 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 Stanimir