Path: ...!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Mon, 24 Mar 2025 18:49:45 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vrs9g9$pnb$2@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org> <vrrjlp$t52$1@reader1.panix.com> <pzdEP.126362$f5K3.26821@fx36.iad>
Injection-Date: Mon, 24 Mar 2025 18:49:45 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="26347"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 2759
Lines: 41

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.

	- Dan C.