|David M. Lloyd||Jul 14, 2012 11:01 am|
|Doug Lea||Jul 14, 2012 11:17 am|
|Stanimir Simeonoff||Jul 14, 2012 1:01 pm|
|√iktor Ҡlang||Jul 14, 2012 1:16 pm|
|Rémi Forax||Jul 14, 2012 2:20 pm|
|Stanimir Simeonoff||Jul 14, 2012 2:58 pm|
|Rémi Forax||Jul 14, 2012 3:44 pm|
|Doug Lea||Jul 15, 2012 3:37 am|
|David Holmes||Jul 15, 2012 4:14 am|
|√iktor Ҡlang||Jul 15, 2012 8:22 am|
|David M. Lloyd||Jul 15, 2012 9:19 am|
|Jed Wesley-Smith||Jul 15, 2012 7:31 pm|
|David Holmes||Jul 15, 2012 7:35 pm|
|David M. Lloyd||Jul 15, 2012 7:43 pm|
|David Holmes||Jul 15, 2012 7:52 pm|
|Jason T. Greene||Jul 20, 2012 11:42 am|
|David Holmes||Jul 20, 2012 6:34 pm|
|David M. Lloyd||Jul 22, 2012 1:47 pm|
|Doug Lea||Jul 23, 2012 3:44 am|
|Subject:||Re: [concurrency-interest] The Atomic*FieldUpdater situation|
|From:||Rémi Forax (for...@univ-mlv.fr)|
|Date:||Jul 14, 2012 2:20:13 pm|
On 07/14/2012 10:01 PM, Stanimir Simeonoff 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.
I agree with you that creating several subclasses is better than the current strategy which use several final field that aren't considered as constant by the VM. The other solution is to mark this field as trusted i.e will not be changed by reflection, which is in my opinion a better solution.
The next question is how to guarantee that the update value as the right type, otherwise you can corrupt the memory by putting a String in an Integer field (and you can't rely on generics for that).
Since there would be a single subclass only instantiated in the JVM there would be no performance loss from multi-site invocations.
You don't care if there are several subclasses because you've put your AtomicReferenceFieldUpdater in a static final field.
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).
yes, far from ideal.
Kind Regards Stanimir
_______________________________________________ Concurrency-interest mailing list Conc...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest