Re: MSI interrupts

On Mon, 24 Mar 2025 13:59:49 +0000, Scott Lurndal wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

>

>

My architecture has a mechanism to perform ATOMIC stuff over multiple
instruction time frames that has the property that a higher priority
thread which interferers with a lower priority thread, the HPT wins
and the LPT fails its ATOMIC event. It is for exactly this reason
that I drag priority through the memory hierarchy--so that real-time
things remain closer to real-time (no or limited priority inversions).

>
Without being able to see this in practice, it's difficult to
speculate as to how well it will actually work in real-world
scenarios.  What is the scope of what's covered by this atomic
thing?

>
Sounds a lot like transactional memory.  Something that has
yet to prove to be usable in the general case.

It is not TM, but can be used to implement TM should you like.
It is a set of instructions that can implement any (known)
ATOMIC process (TestAndSet, TestAndTestAndSet; lock, unlock,
LD-locked, ST-conditional, CompareSwap, CompareDouble, SwapDouble
CompareTriple, SwapTriple, RemoveElement, InsertElement,
MoveElement, ...}
It is basically a recipe book so SW can implement whatever kinds
of ATOMIC things SW wants, leaving HW out of the loop.
you can also consider it a fully pipelined version of LDL and STC
with up to 8 cache lines of data available for the event.

>
Consider something as simple as popping an item off of the front
of a queue and inserting it into an ordered singly-linked list:
In this case, I'm probably going to want to take a lock on the
queue, then lock the list, then pop the first element off of the
queue by taking a pointer to the head.

>
Which can be done with compare and exchange, atomically;
a lock may not be necessary.
>
The insert into an ordered list will likely require a
spin lock (or a reader-writer lock of some form).