From: chris.m.thomasson.1@gmail.com   
      
   On 12/8/2025 1:12 AM, David Brown wrote:   
   > On 08/12/2025 00:17, Chris M. Thomasson wrote:   
   >> 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?   
   >>   
   >   
   > Yes, I meant "lock the bus" - but I might have been overcautious.   
   > However, it seems there is a hidden hardware loop here - the   
   > esmLOCKstore instruction can fail and and the processor jumps back to   
   > the first esmLOCKload instruction.  With that, you don't need to block   
   > other code from running or accessing the bus.   
   >   
   >   
      
   Humm.. For some damn reason it reminds me of a multi lock thing I did a   
   while back. Called it the multex. Consisted of a table of locks. A   
   thread would take the addresses it wanted to lock, hash then into the   
   table, remove duplicates and sorted them and took them all without any   
   fear of deadlock.   
      
   (read all when you get some free time to burn...)   
   https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ   
      
   It kind of seems like it might want to work with Mitch's scheme in a   
   loose sense?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)