[concurrency-interest] The Atomic*FieldUpdater situation

√iktor Ҡlang viktor.klang at gmail.com
Sat Jul 14 16:16:10 EDT 2012


On Sat, Jul 14, 2012 at 10:01 PM, Stanimir Simeonoff
<stanimir at riflexo.com>wrote:

>
>
> 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).
>
>
Yup. Personally I'd rather go Unsafe or extend Atomic rather than use
FieldUpdaters.

Cheers,
√


>
> Kind Regards
> Stanimir
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120714/472c8cd4/attachment.html>


More information about the Concurrency-interest mailing list