Re: MSI interrupts

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.