Re: MSI interrupts

On 3/24/2025 11:49 AM, Dan Cross wrote:

In article <pzdEP.126362$f5K3.26821@fx36.iad>,
Scott Lurndal <slp53@pacbell.net> 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.

 I understand that some mallocs have done it; McRT-Malloc from
Intel, if I'm not mistaken.
 

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).

 I'm sure one could do a lockless pop using a cmp exchange, but I
wanted to a scenario where one would want to hold onto both
locks throughout the critical section for some reason.
I just don't see how this works in the proposed scenario.

You want to hold lock A while lock B us being used? That can be tricky. Well, there is a locking order. Check out this older work of mine, multex:
https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ
Not sure if this is relevant or not.