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 18:49:29 -0400
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <jwvjz8coho7.fsf-monnier+comp.arch@gnu.org>
References: <vqto79$335c6$1@dont-email.me>
	<0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org>
	<vruql2$cv2$3@reader1.panix.com>
	<e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org>
	<vrva4r$9ka$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 25 Mar 2025 23:49:29 +0100 (CET)
Injection-Info: dont-email.me; posting-host="32f3952deabf3f9cd9365c937ba1cce9";
	logging-data="358202"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+XbDQvyrt9Uym/i8fXFH1pZBB4hQZ77EE="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:gnHSfvUzqr9ojQwpawrMQiDOf3c=
	sha1:hv752+ytMhRwQ39DkcQ1VTbRIT0=

Dan Cross [2025-03-25 22:19:07] wrote:
> From what I gather, you've said to just eschew the atomic event
> stuff and build a traditional lock using those primitives.  But
> you have also said that a traditional lock can be silently
> unlocked if the thread holding it (which, apparently, is an
> abstraction known to hardware) is preempted.  It will be like
> the lock had never been acquired.

Here's the misunderstanding: the lock that can be silently taken away
is the lock implemented in the CPU to run an ATOMIC sequence, not the
lock implemented as a data-structure on top of it: once you've run
(atomically) your `lock_acquire`, of course that lock is yours.  The CPU
doesn't even know that this data-structure is a lock and has no
way to steal it.


        Stefan