Path: ...!weretis.net!feeder9.news.weretis.net!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: Tue, 1 Apr 2025 17:39:00 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vsh8bk$per$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <tWhGP.1790040$TBhc.304536@fx16.iad> <vsd2ep$5c9$1@reader1.panix.com> <WrSGP.1475033$eNx6.441549@fx14.iad>
Injection-Date: Tue, 1 Apr 2025 17:39:00 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="26075"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 7653
Lines: 141

In article <WrSGP.1475033$eNx6.441549@fx14.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote:
>Dan Cross wrote:
>> In article <tWhGP.1790040$TBhc.304536@fx16.iad>,
>> EricP  <ThatWouldBeTelling@thevillage.com> wrote:
>>> Also Gol91 VAX VMS Internals and Data Structures v5.2 1991
>>>
>>> All three, Gol91, Gol94, Rus12 have a section on spinlocks and
>>> explicitly say spinlocks synchronize processors, not threads.
>>>
>>> Gol91 pg 172, Gol94 pg 254: "A spinlock is acquired by a processor to
>>> synchronize access to data shared by members of an SMP system."
>> 
>> Also [Gol91], page 173:
>> 
>> |A resource synchronized through elevated IPL on a uniprocessor
>> |is synchronzied through a combination of spinlock and elevated
>> |IPL on an SMP system.  *A thread of execution* running on one
>> |processor acquires a spinlock to serialized access to the data
>> |with *threads of execution* running on other processors.
>> |Before acquiring, the _thread of execution_ raises IPL to block
>> |accesses *by other threads of execution* running on the *same*
>> |processor.
>> 
>> Emphasis added.  Note that the primitives that do the acquiring
>> and holding are threads.
>> 
>> (Note, I already quoted this text from [Gol94] in an earlier
>> response; page 255.)
>
>And I've tried to get you to stop treating the terms "thread of execution"
>and "kernel thread" as equivalent. They are not.

Yes, and what I've tried to explain to you, over and over, is
that in this context it really doesn't matter.  A "kernel
thread" *can run in kernel mode*.

>It says "thread of execution" which as I have explained is not a
>necessarily a kernel thread (or in this case a VMS process).

This is well-known.  It is also irrelevant.  A processor, or
core, or whatever, is simply not a "thread of execution"; it is
the thing that "threads of execution" run on.  You are trying to
ascribe to a physical object the attributes of a logical entity.

>It could be an interrupt or a Dpc, or code triggered as a consequence
>of actions of any of those which has no connection to whichever
>random kernel thread was running on a processor at that time.
>
>All of those "threads of execution" could acquire a spinlock at their
>associated IPL but only one of those is due to the current kernel thread.

Oh, I see your confusion.  The thing you seem to be missing is
that all of those "threads of execution" _are running in the
kernel in the context of some software thread_.  Those software
threads is the entity that owns a spinlock when it's acquired.
In the case of Windows, VMS, etc, usually that's some "kernel
thread", while it is is running in the kernel, but I would not
be surprised if they had other kinds of dedicated software
threads they used only in the kernel for special purposes.

>Even if that was a kernel thread that raised its IPL and performed
>some kernel action, when it tries to lower its IPL < dispatch,
>that can trigger the Dispatcher which may invoke the Scheduler
>and ThreadSwitcher. As that transition into Dispatcher might trigger
>a thread switch, it conceptually[1] dumps its thread register context
>in case a switch is needed.
>
>And all of those consequences which were not directly invoked by the
>current kernel thread but were triggered by it could acquire spinlocks.
>Those triggered "threads of execution" were set up by other
>"threads of execution", some of which may be kernel threads,
>but are unrelated to the currently executing kernel thread.
>
>On entry to the Dispatcher, the register set, the thread of execution,
>conceptually[1] is no longer connected to whichever kernel thread
>was running on the processor. The private processor state information
>maintains a reference to its current kernel thread whose context will be
>restored when it exits the Dispatcher.
>
>[1] I say conceptually because with careful layering of the code for
>entering and leaving the Dispatcher/Scheduler/ThreadSwitcher the OS
>can defer saving some of the kernel thread's registers into the kernel
>thread context until the actual thread switch occurs, as long as it
>does not modify those registers. x64 FPU or SIMD registers might be examples.

I'm sorry, I think you're confused here in a similar manner to
how you were confused about the way system calls work.

>>> Rus12 pg 179: "The mechanism the kernel uses to achieve multiprocessor
>>> mutual exclusion is called a spinlock."
>> 
>> Yes, I already pointed out that this is the usual case.  But you
>> are still ignoring the uniprocessor case: spinlocks must work
>> there, as well.
>> 
>> But more relevantly, this does not imply that _processors_ "own"
>> spinlocks in the way you have asserted.  That is done by
>> threads.  A thread does not magically "turn into" a processor
>> when it acquires a spinlock; it remains a thread, albeit one
>> that is now holding a spinlock that it wasn't before.
>
>I've pointed you at the sections of those books which repeatedly refers to
>them as "processor spinlocks".

No, you really didn't.  You did point to things in the book that
appeared to agree with you, but you cherry-picked those and
ignored the larger context, where it invariably meant something
else that _disagreed_ with your interpretation.  Furthermore,
you ignored anything that didn't already fit your preconception
of how these things fit together.

>Rus12 on pg 181 even shows a WNT kernel
>debugger command in "EXPERIMENT: Viewing Global Queued Spinlocks" which
>    *displays a list of queued spinlocks held by each processor*.
>That list is stored in the Processor Control Region PCR,
>a per-processor status block WNT maintains.
>
>If that is not enough to convince you, nothing will.

Here is another example of cherry-picking out of context.  The
reference here is to queuing spin locks, where Windows tries to
avoid scalability collapse due to cache-coherency overhead when
threads running on different processors race on acquiring a
heavily contended (spin)lock.  The context is obvious in when
one considers the surrounding text in addition to that sentence
fragment: they are clearly talking about concurrent threads
running on different processors racing in parallel.

As an aisde, I already pointed to a paper about th topic of
non-scalable locks in the context of Linux (Boyd-Wickizer et
al): http://pdos.csail.mit.edu/papers/linux:lock.pdf

>I've tried my best to explain it and pointed you to the text that supports
>this but you remain unconvinced and this is just going around in circles
>and using up both of our time. As your interpretation works for you and
>mine works for me, we'll just have to agree to disagree.

Probably for the best.

	- Dan C.