From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   >    
   > >>> 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.   
      
   esmLOCKLoad sets up monitors (in Miss Buffers) that detect Snoops to   
   the participating cache lines.   
      
   esmINTERFERENCE sets up a block of code that either executes in its   
   entirety or fails in its entirety--and transfers control.   
      
   In "certain circumstances" the code inside the esmINTERFERENCE block   
   are allowed to NaK SNOOPs to those lines. So, if interference happens   
   this late, you can effectively tell requestor "Yes, I have that cache   
   line, No you cannot have it right now".   
      
   If requestor gets a NaK, and requestor was attempting an ATOMIC event,   
   the event fails. If requestor was NOT attempting, requestor resubmits   
   the request. In both cases, the thread causing the interference is the   
   one delayed while the one performing the event has higher probability   
   of success.   
      
   > I am assuming the esmLockStore() just unlocks what was previously locked   
   > and the stores have already happened by that time.   
      
   Yes, it is the terminal sentinel.   
      
   > 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()?   
      
   I can see you are getting at something subtle, here. I cannot quite grasp   
   what it might be.   
      
   Can you ask the above again but use different words ?!?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)