Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Tue, 25 Mar 2025 01:53:00 +0000
Organization: Rocksolid Light
Message-ID: <e0080df32c6f88ebbd4c8828f98f76a9@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <kVgEP.1277108$_N6e.605199@fx17.iad> <vrsea2$siu$1@reader1.panix.com> <a86295425dfb043a1b44e550a1c05659@www.novabbs.org> <vrsqrd$ns1$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1623632"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$SVq1GiSqE1tTquLqeJ.FnuX/Sxru0RpuQhASAIh8ebr0qOfWEbmjS
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5974
Lines: 113

On Mon, 24 Mar 2025 23:45:49 +0000, Dan Cross wrote:

> In article <a86295425dfb043a1b44e550a1c05659@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>On Mon, 24 Mar 2025 20:11:46 +0000, Dan Cross wrote:
>>
>>> In article <kVgEP.1277108$_N6e.605199@fx17.iad>,
>>> EricP  <ThatWouldBeTelling@thevillage.com> wrote:
>>>>Dan Cross wrote:
>>>>> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>,
>>>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>-------------------
>>>>This is why I mentioned the terminology thing: threads do not hold
>>>>spinlocks, they hold mutexes.
>>>
>>> See above.  Threads can certainly "hold" a spin lock, as they
>>> can hold any kind of lock.  To quote from sec 7.6.1 of [Val96],
>>> page 202:
>>>
>>> |On a uniprocessor, if a thread tries to acquire a spin lock
>>> |that is already held, it will loop forever.  Multiprocessor
>>> |algorithms, however, must operate correctly regardless of the
>>> |number of processors, which means that they should handle the
>>> |uniprocessor case as well.  This requires strict adherence to
>>> |the rule that threads not relinquish control of the CPU while
>>> |holding a spin lock.
>>
>>My 66000 ATOMIC stuff is designed such that if control has to leave
>>the ATOMIC event, all HW knowledge of being in that event disappears
>>and IP is modified (prior to control transfer) such that upon return
>>SW knows the event failed (or never started), and that no update of
>>participating data in the event ever becomes visible.
>>
>>HW can do this with address-based events, but not with data-based
>>events. LDL-STC are address-based events used to manipulate data-
>>based events. Mine just allow more LDs and STs in the event than 1.
>>
>>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.
>
> I definitely do Not want that property.  Having a lock
> "disappear" on delivery of an interrupt seems like it would be a
> great way to introduce silent corruption.

It means that if a thread owning a lock is interrupted, that
thread gives the lock back--so there is no priority inversion
and no lock-starvation. Associated with the give back, and the
IP of the interrupted thread no longer points inside the
critical section.

Nothing gets lost.

{{Perhaps disappear was a poorly chosen word.}}

> If your atomic primitives are not sufficient to cover an entire
> critical section, as I believe we have established, and are
> mostly intended to be used for building concurrency primitives
> like locks, then I expect that software would take the lock, see
> that it succeeded, and enter the critical section.
>
>                                                     If at that
> point the lock were silently discarded on receipt of an
> interrupt,

At this point your thread in not IN the critical section !!

The closest you can be is at the first instruction beginning
an ATOMIC event (the never happened case) or you can also
be at the point where you KNOW that some other interfered
with your actions, and that they saw a completely consistent
state--now it is your turn (again) observing a completely
consistent but new state.

>            then potentially some other thread could subsequently
> take the lock,

Since you are not in the critical section, you don't care.
No critical data has been modified, there is no inconsistent
state to be observed; and YOUR Instruction Pointer is not
pointing into instructions within the ATOMIC event !!

>                enter the critical section, and observe a data
> structure in an inconsistent state (leading to a crash in the
> best case).

There is no inconsistent state--in rather the same way a core backs
up a branch mispredict, the core backs up the ATOMIC event to appear
as if it never even started !!

>              This is precisely the sort of thing we build mutual
> exclusion primitives to wrap around critical sections to avoid.

And also why those primitives give rise to priority inversion
and lock-starvation.

> If, on the other hand, the atomic primitives are just meant for
> the spin loop, then I don't really see how that's all that
> useful compared to LL/SC.

Any number of respected people have ask for a pipelined LL-SC;
where one can LL multiple datums and later SC multiple datums.
This is what ESM can provide.

>                            And you still need some way to ensure
> that the critical section is not interrupted.

Just a way to detect if it happened; and if it happens;
means to back upto a point where it does not matter if
interference happened "right there"--that is: outside of
a critical section.

> 	- Dan C.