Re: MSI interrupts

On Mon, 24 Mar 2025 20:28:40 +0000, Dan Cross wrote:

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

On Mon, 24 Mar 2025 18:02:25 +0000, Stefan Monnier wrote:
>

MitchAlsup1 [2025-03-24 17:36:28] wrote:

On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote:

Consider something as simple as popping an item off of the front
of a queue and inserting it into an ordered singly-linked list:

[...]

I have almost that in the documentation for my ATOMIC stuff::
The following code moves a doubly linked element from one place
in a concurrent data structure to another without any interested
3rd party being able to see that the element is now within the
CDS at any time::

>
Would your "ATOMIC stuff" really handle Dan's example, tho?
A key element in Dan's example if the "ordered singly-linked list",
i.e. you need to walk the list an unbounded number of steps until you
can find the insertion point, so I don't think you can do the whole
thing inside your ATOMIC stuff.

>
Technically, yes, you can put a search loop in an ATOOMIC event.
Whether you want to or not is a different story. My example
illustrated the ATOMIC manipulation of the event without a search.
>
In addition, if the search it long, code developer should either
to the search before the event, or grab a Mutex to prevent
interference during the search and rest of the critical region.

>
The problem, as specified, excluded this idea that the list was
long.
>
The point was simply to show a scenario where your atomic
operation proposal breaks down, and where you might want to
disable interrupt delivery.

My ATOMIC stuff allows for the construction, in SW, of pretty
much any ATOMIC primitive anyone would like. It is, in general,
not suited to guard critical regions, but to grab the lock which
does.
Most uses of My ATOMIC stuff is to grab/change/update data
that then guards various critical regions. More like a multi-
valued version of LDL-STC.

                             The point wasn't to ask whether
the specific problem could be recast in a different way; it
probably can.  The question was to ask whether your proposal
could support that specific problem.  I don't see how it can.

To the question posed, you should just grab the lock/mutex.

IOW, you'd have to somehow move the list-walk outside of the atomic
section.

>
Yes,
>

E.g. if you know elements are only ever removed from the tail of the
list, you can presumably walk the list outside of the ATOMIC stuff and
then do the "remove from the queue and insert into the list" atomically
since it's a small&finite number of steps (with a test to loop back to
the list-walk if someone else inserted or removed anything at that point
in the mean time).

>
Or maintain a tail pointer.

>
There's no guarantee that the tail is the correct place to
insert the element, vis the order of the elements.

If the element pointer updates and the tail pointer update are inside
one of my ATOMIC events, then you are sure that the tail pointer is
always pointing at the last element in the list (if there is one).

- Dan C.