From: kegs@provalid.com   
      
   In article <20251201132322.000051a5@yahoo.com>,   
   Michael S   wrote:   
   >On Mon, 01 Dec 2025 07:56:37 GMT   
   >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
   [snip]   
   >> If hardware designers put their mind to it, they could make sequential   
   >> consistency perform well, probably better on code that actually   
   >> accesses data shared between different threads than weak and "strong"   
   >> ordering, because there is no need to slow down the program with   
   >> fences and the like in cases where only one thread accesses the data,   
   >> and in cases where the data is read by all threads.  You will see the   
   >> slowdown only in run-time cases when one thread writes and another   
   >> reads in temporal proximity.  And all the fences etc. that are   
   >> inserted just in case would also become fast (noops).   
   >>   
   >   
   >Where does sequential consistency simplifies programming over x86 model   
   >of "TCO + globally ordered synchronization primitives +   
   >every synchronization primitives have implied barriers"?   
   >   
   >More so, where it simplifies over ARMv8.1-A, assuming that programmer   
   >does not try to be too smart and never uses LL/SC and always uses   
   >8.1-style synchronization instructions with Acquire+Release flags set?   
   >   
   >IMHO, the only simple thing about sequential consistency is simple   
   >description. Other than that, it simplifies very little. It does not   
   >magically make lockless multithreaded programming bearable to   
   >non-genius coders.   
      
   Compiler writers have hidden behind the hardware complexity to make   
   writing source code that is thread-safe much harder than it should be.   
   If you have to support placing hardware barriers, then the languages   
   can get away with needing lots of  qualifiers everywhere, even   
   on systems which don't need barriers, making the code more complex.  And   
   language purists still love to sneer at volatile in C-like languages as   
   "providing no guarantees, and so is essentially useless"--when volatile   
   providing no guarantees is a language and compiler choice, not something   
   written in stone.  A bunch of useful algorithms could be written with   
   merely "volatile" like semantics, but for some reason, people like the   
   line-noise-like junk of C++ atomics, where rather than thinking in terms   
   of the algorithm, everyone needs to think in terms of release and acquire.   
   (Which are weakly-ordering concepts).   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)