From: chris.m.thomasson.1@gmail.com   
      
   On 12/8/2025 4:31 PM, Chris M. Thomasson wrote:   
   > On 12/8/2025 9:14 AM, Scott Lurndal wrote:   
   >> Stephen Fuld  writes:   
   >>> 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.   
   >>   
   >> Sounds very much similar to the ARMv8 concept of an "exclusive monitor"   
   >> (the basis of the Store-Exclusive/Load-Exclusive instructions, which   
   >> mirror the LL/SC paradigm).  The ARMv8 monitors an implementation defined   
   >> range surrounding the target address and the store will fail if any other   
   >> agent has modified any byte within the exclusive range.   
   >   
   > Any mutation the reservation granule?   
      
   I forgot if a load from the reservation granule would cause a LL/SC to   
   fail. I know a store would. False sharing in poorly written programs   
   would cause it to occur. LL/SC experiencing live lock. This was back in   
   my PPC days.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)