From: user5857@newsgrouper.org.invalid
"Chris M. Thomasson" posted:
> 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.
This is why NaKing the interference works better. The interfering agent
takes the timing hit while the ATOMIC event has higher probability of
success.
Also Note: esm is not subject to ABA problem at all--because any interrupt
or exception causes the event to terminate prior to control transfer.
And this is ALSO why there is no thread state associated with esm --
excepting the 16-bit WHY value which is only set if/when there are
no {E,I} control transfers.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
