Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Thu, 27 Mar 2025 19:09:14 -0700
Organization: A noiseless patient Spider
Lines: 602
Message-ID: <vs50cb$1jq5h$2@dont-email.me>
References: <vqto79$335c6$1@dont-email.me>
 <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org>
 <vs41ap$n43$1@reader1.panix.com>
 <601781e2c91d42a73526562b419fdf02@www.novabbs.org>
 <vs4se6$hvb$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Mar 2025 03:09:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7ce1f9b3539f865da57caab62bfa1cad";
	logging-data="1697969"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0cqr1e9PAkFbmRdsxo6dUPjHqP8fCVL8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:quGxYCTjr9ooDBg8MIpxftCxz7I=
Content-Language: en-US
In-Reply-To: <vs4se6$hvb$1@reader1.panix.com>

On 3/27/2025 6:01 PM, Dan Cross wrote:
> 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
========== REMAINDER OF ARTICLE TRUNCATED ==========