From: user5857@newsgrouper.org.invalid   
      
   "Chris M. Thomasson"  posted:   
      
   > On 12/5/2025 12:54 PM, 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.   
   > >   
   > > Compare Double, Swap Double::   
   > >   
   > > BOOLEAN DCAS( type oldp, type_t oldq,   
   > >                type *p,   type_t *q,   
   > >                type newp, type newq )   
   > > {   
   > >       type t = esmLOCKload( *p );   
   > >       type r = esmLOCKload( *q );   
   > >       if( t == oldp && r == oldq )   
   > >       {   
   > >                          *p = newp;   
   > >            esmLOCKstore( *q,  newq );   
   > >            return TRUE;   
   > >       }   
   > >       return FALSE;   
   > > }   
   > >   
   > > Move Element from one place to another:   
   > >   
   > > BOOLEAN MoveElement( Element *fr, Element *to )   
   > > {   
   > >       Element *fn = esmLOCKload( fr->next );   
   > >       Element *fp = esmLOCKload( fr->prev );   
   > >       Element *tn = esmLOCKload( to->next );   
   > >       esmLOCKprefetch( fn );   
   > >       esmLOCKprefetch( fp );   
   > >       esmLOCKprefetch( tn );   
   > >       if( !esmINTERFERENCE() )   
   > >       {   
   > >                     fp->next = fn;   
   > >                     fn->prev = fp;   
   > >                     to->next = fr;   
   > >                     tn->prev = fr;   
   > >                     fr->prev = to;   
   > >       esmLOCKstore( fr->next,  tn );   
   > >                     return TRUE;   
   > >       }   
   > >       return FALSE;   
   > > }   
   > >   
   > > So, I guess, you are not talking about what My 66000 cannot do, but   
   > > only what other ISAs cannot do.   
   >   
   > Any issues with live lock in here?   
      
   A bit hard to tell because of 2 things::   
   a) I carry around the thread priority and when interference occurs,   
      the higher priority thread wins--ties the already accessed thread wins.   
   b) live-lock is resolved or not by the caller to these routines, not   
      these routines themselves.   
   >   
   > [...]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)