From: chris.m.thomasson.1@gmail.com   
      
   On 12/13/2025 11:03 AM, MitchAlsup wrote:   
   >   
   > "Chris M. Thomasson"  posted:   
   >   
   >> 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.   
   >   
   > A LD to the granule would cause loss of write permission, causing a long   
   > delay to perform SC and greatly increase the probability of interference.   
      
   So, you need to create a rule. If you program for my system, you MUST   
   make sure that everything is properly aligned and padded. Been there,   
   done that. Now, think of nefarious agents... I was able to cause damage   
   to a simple strong CAS loop with another thread(s) mutating the cache   
   line on purpose, as a stress test... CAS would start hitting higher and   
   higher failure rates, and finally, hit the BUS to ensure some sort of   
   forward progress.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)