[concurrency-interest] Concurrency-interest Digest, Vol 148, Issue 16

Alex Otenko oleksandr.otenko at gmail.com
Thu May 25 17:30:22 EDT 2017


Also, a FullFence only after the CAS won’t do. You also need the fence to make sure the volatile read does not reorder with anything preceding CAS.

Alex
 
> On 25 May 2017, at 22:24, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
> 
> This is an absolutely necessary promise.
> 
> The programs that benefit from such promise can reduce contention by detecting contenders (failed CAS does not mean you have to hammer it until you get a successful CAS) and by facilitating cooperation (if you can distinguish a CAS in the past from the CAS in the future, you can stop contending for resources).
> 
> Alex
> 
>> On 25 May 2017, at 21:01, Mike Duigou <openjdk at duigou.org> wrote:
>> 
>> 
>>> And so, Mike: Some existing code might rely on this, so the best we
>>> could so here is replace elided volatile-write with a fullFence,
>>> which would probably not be detectably faster.
>> 
>> Another one bites the dust. A disappointing and frustrating but familiar conclusion--being blocked from reasonable beneficial improvements by the specification making unnecessary promises or by what some weird program that may or might expect. Having been there I am not envious of those working the JDK libraries.
>> 
>> Mike
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 



More information about the Concurrency-interest mailing list