Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Tue, 25 Mar 2025 01:26:00 -0400
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <jwvmsd91yxy.fsf-monnier+comp.arch@gnu.org>
References: <vqto79$335c6$1@dont-email.me>
	<kVgEP.1277108$_N6e.605199@fx17.iad> <vrsea2$siu$1@reader1.panix.com>
	<a86295425dfb043a1b44e550a1c05659@www.novabbs.org>
	<vrsqrd$ns1$1@reader1.panix.com>
	<e0080df32c6f88ebbd4c8828f98f76a9@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 25 Mar 2025 06:26:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="459b3773d73d9f41b36f6a561e834817";
	logging-data="2678465"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/gSK1UP8dwUue3jx6zaCQAj9olwvILts0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:XTA8ZPHrpVctHxV7tFPAaBlryrk=
	sha1:nrFFNGKceXtn/g0U5SPpRbk1TH0=

> It means that if a thread owning a lock is interrupted, that
> thread gives the lock back--so there is no priority inversion
> and no lock-starvation. Associated with the give back, and the
> IP of the interrupted thread no longer points inside the
> critical section.

I think the discussion is a bit confusing because we have 2 different
notions of "critical section" at play, here:

Mitch's ESM/ATOMIC provides a kind of middle-point between LL/SC and
transactional memory, which handles only "very small" atomic sequences
(IIUC there's no limit to the number of instructions, but there's
a limit of 8 data cache lines touched).

A "critical section" can refer to such an atomic sequence.  But that can
be used only for critical sections of limited size, so as you point out
it can't really be composed.  For this reason, as Mitch said, it's meant
mostly as a tool to implement synchronization primitives (lock,
semaphore, read/write lock, younameit), tho it seems sufficiently
flexible that it should also be usable for some lock-free operations.

A "critical section" can also refer to the arbitrary code protected by
a lock, where the lock primitives would be presumably themselves
implemented using ESM and would then each be made of their own "critical
section".

The small ATOMIC-style critical sections don't hold locks.  Instead they
use an optimistic-synchronization approach, which is why they don't
suffer from priority inversion.

The lock-based critical sections you can build on top of the ATOMIC-style
critical sections, OTOH, are just your usual lock-based critical
sections: the fact that they're built out of ESM primitives rather than
out of test&set or LL/SC doesn't really make any difference: they can
indeed suffer from priority inversion.


        Stefan