Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Mon, 24 Mar 2025 12:12:56 -0700
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <vrsaro$1faj3$9@dont-email.me>
References: <vqto79$335c6$1@dont-email.me>
 <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org>
 <vrrjlp$t52$1@reader1.panix.com> <pzdEP.126362$f5K3.26821@fx36.iad>
 <vrs9g9$pnb$2@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Mar 2025 20:12:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="134859492fb1e605dc9ff2cb841b4e25";
	logging-data="1550947"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+y0tXuU5i6Df/HLtLomfT7o4Er2C1CIVg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Mwk+FbaXn3wy7TpFcFaBIUdFQEw=
Content-Language: en-US
In-Reply-To: <vrs9g9$pnb$2@reader1.panix.com>
Bytes: 3411

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.