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:Doug Lea (dl@cs.oswego.edu)
Date:Jul 15, 2012 3:37:38 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? ...

Is there any recourse to solve this issue?

So to summarize for the moment: Whenever this issue comes up, there seem to be some upcoming options that will someday provide good solutions. Along with some shorter-term bandaids that would make them a little better in some cases. We always end up not applying the bandaids because nearly all the people impacted by the performance issues are developing infrastructure-level components, and know how to correctly encapsulate "Unsafe" bypasses. This is ugly and uncomfortable, but still probably better than alternatives. I think the main downside is that people not in that category reading source code can get the impression that using Unsafe directly for atomic and fenced accesses is a recommended technique rather than an act of desperation.

-Doug