Re: Concurrency-interest Digest, Vol 148, Issue 16

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Concurrency-interest Digest, Vol 148, Issue 16

Mike Duigou

> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Concurrency-interest Digest, Vol 148, Issue 16

Alex Otenko
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 <[hidden email]> 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
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Concurrency-interest Digest, Vol 148, Issue 16

Alex Otenko
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...