19 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] The Atomic...| From | Sent On | Attachments |
|---|---|---|
| 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: | Doug Lea (dl...@cs.oswego.edu) | |
| Date: | Jul 14, 2012 11:17:46 am | |
| List: | edu.oswego.cs.concurrency-interest | |
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.
I mean I'm using field updaters in the first place because I can't afford to have a jillion Atomic* objects floating around; obviously performance is critical here. And to add to this problem, you can't even rely on using Unsafe, even though it's becoming more and more prevalent in JDKs, as some platforms may not have atomic 64-bit operations, and there's no way I can see to test for that other than relying on the AtomicLong implementation to be similar to OpenJDK's.
We stopped using Updaters entirely inside j.u.c as of JDK7 and use straight Unsafe calls without even checking for 64bit atomics. Which means that we are relying on every JDK7+ VM to somehow implement the 64bit version of Unsafe CAS. So if you are targeting JDK7+ only, you might take some comfort that if j.u.c cannot run, then it probably doesn't matter if your code runs, and so don't worry about the checks :-)
Is there any recourse to solve this issue?
Maybe someday. Remi Forax has mentioned a few times that JDK8 method handle and invokeDynamic support should make this or some variant API a lot faster. We'll see...
-Doug
_______________________________________________ Concurrency-interest mailing list Conc...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest