Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Stefan Monnier 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: References: 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