Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Fri, 28 Mar 2025 01:01:59 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vs4se6$hvb$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org> <vs41ap$n43$1@reader1.panix.com> <601781e2c91d42a73526562b419fdf02@www.novabbs.org>
Injection-Date: Fri, 28 Mar 2025 01:01:59 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="18411"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)

In article <601781e2c91d42a73526562b419fdf02@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Thu, 27 Mar 2025 17:19:21 +0000, Dan Cross wrote:
>> In article <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote:
>>>> [snip]
>>>> 1. `from` may point to a cache line
>>>> 2. `to` may point to a different cache line.
>>>> 3. Does your architecture use a stack?
>>>
>>>No
>>
>> You make multiple references to a stack just below.  I
>> understand stack references are excluded from the atomic event,
>> but I asked whether the architecture uses a stack.  Does it, or
>> doesn't it?
>>
>>>>    What sort of alignment criteria do you impose?
>>>
>>>On the participating data none. On the cache line--cache line.
>>
>> I meant for data on the stack.  The point is moot, though, since
>> as you said stack data does not participate in the atomic event.
>
>Stack does not NECESSARILY participate. However, if you perform
>a esmLOCKload( SP[23] ) then that line on the stack is participating.

Very good.

>>>>    At first blush, it seems to me that
>>>>    the pointers `from_next`, `from_prev`, and `to_next` could be
>>>>    on the stack and if so, will be on at least one cache line,
>>>>    and possibly 2, if the call frame for `MoveElement` spans
>>>>    more than one.
>>>
>>>The illustrated code is using 6 participating cache lines.
>>>Where local variables are kept (stack, registers) does not
>>>count against the tally of participating cache lines.
>>
>> Huh.
>
>There are 6 esmLOCKxxxxx() so there are 6 participating lines--
>and these are absolutely independent from where the variables
>are located. The variables carry information but do not part-
>ticipate they carry data between operations on the particupating
>lines.

That was clearly in the code.  That was not what the "Huh" was
in resposne to.

>>       How would this handle something like an MCS lock, where
>> the lock node may be on a stack, though accessible globally in
>> some virtual address space?
>
>As illustrated above esmLOCKload( SP[23]) will cause a line on
>the stack to participate in the event.

Ok, good to know.

>----------------
>>>> But later you wrote,
>>>>
>>>>>So, if you want the property whereby the lock disappears on any
>>>>>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>>>>>then you want to use my ATOMIC stuff; otherwise, you can use the
>>>>>normal ATOMIC primitives everyone and his brother provide.
>>>>
>>>> Well, what precisely do you mean here when you say, "if you want
>>>> the property whereby the lock disappears on any control transfer
>>>> out of the event"?
>>>
>>>If you want that property--you use the tools at hand.
>>>If you don't just use them as primitive generators.
>>
>> I wasn't clear enough here.  I'm asking what, exactly, you mean
>> by this _property_,
>
>The property that if an interrupt (or exception or SVC or SVR)
>prevents executing the event to its conclusion, HW makes the
>event look like it never started. So that when/if control returns
>we have another chance to execute the event as-if ATOMICally.

Ok.  So let's be crystal clear here: after the event concludes
successfully, a subsequent exception, interrupt, or whatever,
will not magically roll back any of the values set and made
visible system-wide as a result of the successful conclusion of
the atomic event.  Correct?  That's what I've been asking.

>>                     not what you mean when you write that one
>> can use these atomic events if one wants the property.  That is,
>> I'm asking you to precisely define what it means for a lock to
>> "disappear".
>>
>> It seems clear enough _now_ that once the event concludes
>> successfully the lock value is set to whatever it was set to in
>> during the event, but that wasn't clear to me earlier and I
>> wanted confirmation.
>
>Not "the lock value" but "all participating values" are set
>and become visible system-wide in a single instant.

Sure.  But there was only one participating value in the
spinlock example.  ;-}

>No 3rd
>party sees some set and others remain unset. Everybody sees
>all of then change value between this-clock and its successor.

Sure.  You've said this all along, and I've never disputed it.

>> In particular, it seems odd to me that one would bother with a
>> lock of some kind during an event if it didn't remain set after
>> the event.
>
>Consider CompareTripleSwapFour() as an atomic primitive. How
>would you program this such that nobody nowhere could ever
>tell that the four updated locations changes in any order
>then simultaneously ??? Without using a LOCK to guard the
>event ??? And without demanding that all four updates are
>to the same cache line ???
>
>{{Nobody nowhere included ATOMIC-blind DMA requests}}

The fundamental issue here is that, when I refer to a "lock" I
have been talking about a software mutual exclusion primitive,
and you are referring to something else entirely.

I would have thought my meaning was clear from context;
evidently not.

>>             If you do all of your critical section stuff inside
>> of the event, and setting the lock in the event is not visible
>> until the event concludes, why bother?  If on the other hand you
>> use the event to set the lock, why bother doing additional work
>> inside the event itself, but in this case I definitely don't
>> want something else to come along and just unset the lock on its
>> own, higher priority or not.
>
>It is clear you do not understand the trouble HW takes to implement
>even DCADS where between any 2 clocks, one (or more) SNOOPs can
>take the lines you are DCADSing. It is this property of cache
>coherence that gets in the way of multi-operation ATOMIC events.

As above, when I refer to "setting the lock" I am referring to
acquiring a mutex; a software primitive.  I am not referring to
what the hardware does internally.  Consider what I wrote above,
the section that you quoted, in that context.

>In 2004 Fred Weber came to me and ask: "Why can't we (AMD) give
>Microsoft the DCADS they want. I dug into it, and ASF was my
>solution in x86 ISA, ESM is my solution in RISC-based ISA. It
>removes the need to add ATOMIC primitives to ISA over generations.
>
>It also provides the ability to do other things--which apparently
>you will not use--sort of like complaining that your new car has
>auto-park a feature you will never use.

"It is clear you do not understand the trouble SW takes to
implement even simple things that are beyond the capability of
hardware."

(Back at you.  I think I've been pretty polite here; I'm getting
tired of the barbs.)

>>>> What I _hope_ you mean is that if you transfer "out of the
>>>> event" before the `esmLOCKstore` then anything that's been done
>>>> since the "event" started is rolled back, but NOT if control
>>>> transfer happens _after_ the `esmLOCKstore`.  If THAT were the
>>>> case, then this entire mechanism is useless.
>>>
>>>One can use a esmLOCKstore( *SP, 0 ) to abandon an event. HW
>>>detects that *SP is not participating in the event, and uses
>>>the lock bit in the instruction to know it is time to leave
>>>the event in the failed manner. No ST is performed to the
>>>non-participating cache line. {{I guess I could wrap the
>>>abandonment into a macro ...}}
>>
>> Again, not what I was asking.  I'm trying to understand what you
>> meant when you talked about disappearing locks.
>
>If the event cannot be completed due to interrupt or exception or
>SCVC or SVR, the HW backs up the event such that is looks like
>it never started. SO when control return, the ATOMIC event runs
>in its entirety ATOMICally !! So, the illusion of ATOMICITY is
>preserved.
========== REMAINDER OF ARTICLE TRUNCATED ==========