From: david.brown@hesbynett.no   
      
   On 08/12/2025 17:23, Stephen Fuld wrote:   
   > On 12/8/2025 4:25 AM, Robert Finch wrote:   
   >>    
      
   >> 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.   
   >   
      
   Yes, that is correct (as far as I understand it now).  The critical part   
   is the hidden hardware loop that was not mentioned or indicated in the   
   original code.   
      
   There are basically two ways to handle atomic operations.  One way is to   
   use locking mechanisms to ensure that nothing (other cores, interrupts   
   or other pre-emption on the same core) can break up the sequence.  The   
   other way is to have a mechanism to detect conflicts and a failure of   
   the atomic operation, so that you can try again (or otherwise handle the   
   situation).  (You can, of course, combine these - such as by disabling   
   local interrupts and detecting conflicts from other cores.)   
      
   The code Mitch posted apparently had neither of these mechanisms, hence   
   my confusion.  It turns out that it /does/ have conflict detection and a   
   hardware retry loop, all hidden from anyone trying to understand the   
   code.  (I can appreciate that there may be benefits in doing this in   
   hardware, but there are no benefits in hiding it from the programmer!)   
      
   >   
   >> 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.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)