[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Alex Otenko oleksandr.otenko at gmail.com
Sun May 28 05:12:33 EDT 2017


I think the answer to your question is in the absence of such systems.

Also, I can agree to a statement that “that model of core to core data synchronization has never really proven to be THE solution” (implying universal quantifier), but I find the statement with “…to be A solution” not self-consistent (can’t eliminate existential quantifier in the presence of the evidence of existence).

Our processors are working at latencies where the speed of light vs the size of the die becomes a limiting factor - until we find a way for spatially separated physical bodies to interact at speeds faster than light, or for the space around the die to become radically warped. Until then we can only learn to take advantage of local interactions being observed sooner than remote interactions.

Alex


> On 28 May 2017, at 02:19, Gregg Wonderly <gergg at cox.net> wrote:
> 
> If there are 5 stores before that store, and it’s those values, plus the CAS target that move your state forward, then the fence on CAS can be vital to correct software.  Since the MM interactions are costly, they are always targets for elimination by systems architects and developers who are aware of those details.  Processors with huge, costly MM interactions are the bigger concern.  Why are we still fighting against the processor, instead of having highly performant systems which don’t care about the processor?  That’s a big question that I’ve asked for more than a decade now.  We keep coming back around to micromanaging cache lines and other MM interactions in our software because that model of core to core data synchronization has never really proven to be a solution as much as it is a reason why software can be randomly wrong.
> 
> Gregg
> 
> 
>> On May 26, 2017, at 3:44 AM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 25/05/17 18:15, Gil Tene wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On May 25, 2017, at 3:42 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>> 
>>>>> On 05/25/2017 06:16 AM, Andrew Haley wrote:
>>> 
>>> While on this subject, was the relative "weakening" of compareAndSet (and other) memory semantics between Java 8 and java 9 discussed elsewhere? 
>>> 
>>> In java 8, a compareAndSet has the memory semantics of a volatile write regardless of whether or not the write occurred. In java 9 it only has a volatile write effect if the write occurs. While the loosening in the non-writing case may allow for additional optimizations, I worry that it may break existing code that could rely on the previous behavior.
>> That property of compareAndSet is very ugly, and is a pain to implement.
>> Most of the CAS instructions I know about don't have such a property,
>> and making it work requires either an unconditional full fence after every
>> CAS or a conditional one if it fails.  Either way sucks mightily and
>> is unlikely to be useful except in the most pathological cases.
>> 
>> Besides, how does it ever make sense to synchronize with a store that
>> never happened?
>> 
>> -- 
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> _______________________________________________
> 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