Path: ...!weretis.net!feeder9.news.weretis.net!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: Wed, 26 Mar 2025 04:40:43 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vs00gb$f3$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <jwvjz8coho7.fsf-monnier+comp.arch@gnu.org> <vrvegn$fv9$2@reader1.panix.com> <jwv34f0o75h.fsf-monnier+comp.arch@gnu.org>
Injection-Date: Wed, 26 Mar 2025 04:40:43 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="483"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3010
Lines: 42

In article <jwv34f0o75h.fsf-monnier+comp.arch@gnu.org>,
Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>> Even so, I don't see the point of the proposed atomic framework.
>> It seems to have no significant advantage over a more
>> traditional scheme; CAS, LL-SC, whatever seem more general and
>> less intertwined with primitives that the hardware has no real
>> business injecting itself into (like threads).
>
>AFAICT it's somewhat similar to ARM's LL/SC (which can also cover some
>number of cache lines) except that it takes care of looping for you: if
>the final store fails because of interference My 66000 will "simply" abort
>the whole operation (reusing the speculation hardware) and start over,
>instead of having to write an explicit loop.
>
>Without actual hardware and software to try it's hard to assess how well
>it's going to work, but the design sounds good: it should lead to more
>compact code than LL/SC, be more general/friendly to lock-free coding
>than T&S/C&S, and also compared to LL/SC it should behave better under
>high contention because it is careful to guarantee overall forward
>progress (in case of conflict between two cores, at least one of them
>can finish successfully).

Ah, thanks, Stefan.  That makes more sense.

Perhaps some day there will be hardware and systems software and
we can see how it actually works out in practice.  I remain
skeptical given the example code that was posted, and it appears
that the claims are still just that: claims.

Regardless, if anyone has the sort of track record to
demonstrate that they can pull it off on the hardware side,
Alsup certainly does, so maybe my skepticism is overly
pessimistic and unwarranted.

	- Dan C.

>IIRC there's also some kind of mechanism to retry more cleverly, i.e. so
>that when N cores are in conflicts, not only one of them succeeds, but
>the N-1 remaining cores have a fighting chance of avoiding bumping into
>each other next time around.  I don't know the details, tho, and IIUC
>this is not automatic: some relevant info is provided but it's up to the
>code to do something useful with it.