Re: MSI interrupts

On Mon, 24 Mar 2025 20:11:46 +0000, Dan Cross wrote:

In article <kVgEP.1277108$_N6e.605199@fx17.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote:

Dan Cross wrote:

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

-------------------

This is why I mentioned the terminology thing: threads do not hold
spinlocks, they hold mutexes.

>
See above.  Threads can certainly "hold" a spin lock, as they
can hold any kind of lock.  To quote from sec 7.6.1 of [Val96],
page 202:
>
|On a uniprocessor, if a thread tries to acquire a spin lock
|that is already held, it will loop forever.  Multiprocessor
|algorithms, however, must operate correctly regardless of the
|number of processors, which means that they should handle the
|uniprocessor case as well.  This requires strict adherence to
|the rule that threads not relinquish control of the CPU while
|holding a spin lock.

My 66000 ATOMIC stuff is designed such that if control has to leave
the ATOMIC event, all HW knowledge of being in that event disappears
and IP is modified (prior to control transfer) such that upon return
SW knows the event failed (or never started), and that no update of
participating data in the event ever becomes visible.
HW can do this with address-based events, but not with data-based
events. LDL-STC are address-based events used to manipulate data-
based events. Mine just allow more LDs and STs in the event than 1.
So, if you want the property whereby the lock disappears on any
control transfer out of the event {exception, interrupt, SVC, SVR, ...};
then you want to use my ATOMIC stuff; otherwise, you can use the
normal ATOMIC primitives everyone and his brother provide.