From: sfuld@alumni.cmu.edu.invalid   
      
   On 12/8/2025 4:25 AM, Robert Finch wrote:   
   >    
   >>>> BOOLEAN RemoveElement( Element *fr )   
   >>>> {   
   >>>>      fn = esmLOCKload( fr->next );   
   >>>>      fp = esmLOCKload( fr->prev );   
   >>>>      esmLOCKprefetch( fn );   
   >>>>      esmLOCKprefetch( fp );   
   >>>>      if( !esmINTERFERENCE() )   
   >>>>      {   
   >>>>                    fp->next = fn;   
   >>>>                    fn->prev = fp;   
   >>>>                    fr->prev = NULL;   
   >>>>      esmLOCKstore( fr->next,  NULL );   
   >>>>                    return TRUE;   
   >>>>      }   
   >>>>      return FALSE;   
   >>>> }   
   >>>>   
   >>>>>   
   >>>>> [*] For which atomic compare-and-swap or atomic swap is generally   
   >>>>> sufficient.   
   >>>   
   >>> Yes, you can add special instructions.   However, the compilers will   
   >>> be unlikely   
   >>> to generate them, thus applications that desired the generation of   
   >>> such an   
   >>> instruction would need to create a compiler extension (like gcc   
   >>> __builtin functions)   
   >>> or inline assembler which would then make the program that uses the   
   >>> capability both compiler   
   >>> specific _and_ hardware specific.   
   >>   
   >> So, in other words, if you can't put it in every ISA known to man,   
   >> don't bother making something better than existent ?!?   
   >>   
   >>> Most extant SMP processors provide a compare and swap operation, which   
   >>> are widely supported by the common compilers that support the C and C++   
   >>> threading functionality.   
   >   
   > I am having trouble understanding how the block of code in the   
   > esmINTERFERENCE() block is protected so that the whole thing executes as   
   > a unit. It would seem to me that the address range(s) needing to be   
   > locked would have to be supplied throughout the system, including across   
   > buffers and bus bridges. It would have to go to the memory coherence   
   > point. Otherwise, some other device using a bridge could update the same   
   > address range in the middle of an update.   
      
   I may be wrong about this, but I think you have a misconception.  The   
   ESM doesn't *prevent* interference, but it *detect* interference.  Thus   
   nothing is required of other cores, no locks, etc.  If they write to a   
   "protected" location, the write is allowed, but the core in the ESM is   
   notified, so it can redo the ESM protected code.   
      
      
   > I am assuming the esmLockStore() just unlocks what was previously locked   
   > and the stores have already happened by that time.   
      
   There is no "locking" in the sense of preventing any accesses.   
      
      
   --   
     - Stephen Fuld   
   (e-mail address disguised to prevent spam)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)