From: chris.m.thomasson.1@gmail.com   
      
   On 12/6/2025 5:42 AM, David Brown wrote:   
   > On 05/12/2025 21:54, MitchAlsup wrote:   
   >>   
   >> David Brown  posted:   
   >>   
   >>> On 05/12/2025 18:57, MitchAlsup wrote:   
   >>>>   
   >>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:   
   >>>>   
   >>>>> David Brown  writes:   
   >>>>>> "volatile" /does/ provide guarantees - it just doesn't provide enough   
   >>>>>> guarantees for multi-threaded coding on multi-core systems.   
   >>>>>> Basically,   
   >>>>>> it only works at the C abstract machine level - it does nothing that   
   >>>>>> affects the hardware.  So volatile writes are ordered at the C level,   
   >>>>>> but that says nothing about how they might progress through storage   
   >>>>>> queues, caches, inter-processor communication buses, or whatever.   
   >>>>>   
   >>>>> You describe in many words and not really to the point what can be   
   >>>>> explained concisely as: "volatile says nothing about memory ordering   
   >>>>> on hardware with weaker memory ordering than sequential consistency".   
   >>>>> If hardware guaranteed sequential consistency, volatile would provide   
   >>>>> guarantees that are as good on multi-core machines as on single-core   
   >>>>> machines.   
   >>>>>   
   >>>>> However, for concurrent manipulations of data structures, one wants   
   >>>>> atomic operations beyond load and store (even on single-core systems),   
   >>>>   
   >>>> Such as ????   
   >>>   
   >>> Atomic increment, compare-and-swap, locks, loads and stores of sizes   
   >>> bigger than the maximum load/store size of the processor.   
   >>   
   >> My 66000 ISA can::   
   >>   
   >> LDM/STM can LD/ST up to 32   DWs   as a single ATOMIC instruction.   
   >> MM      can MOV   up to 8192 bytes as a single ATOMIC instruction.   
   >>   
   >   
   > The functions below rely on more than that - to make the work, as far as   
   > I can see, you need the first "esmLOCKload" to lock the bus and also   
   > lock the core from any kind of interrupt or other pre-emption, lasting   
   > until the esmLOCKstore instruction.  Or am I missing something here?   
      
   Lock the BUS? Only when shit hits the fan. What about locking the cache   
   line? Actually, I think we can "force" an x86/x64 to lock the bus if we   
   do a LOCK'ed RMW on memory that straddles cache lines?   
      
   [...]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)