From: robfi680@gmail.com   
      
      
   >>> 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 am assuming the esmLockStore() just unlocks what was previously locked   
   and the stores have already happened by that time.   
      
   It would seem that esmINTERFERENCE() would indicate that everybody with   
   access out to the coherence point has agreed to the locked area? Does   
   that require that all devices respect the esmINTERFERENCE()?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)