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: Thu, 27 Mar 2025 18:34:00 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vs45mo$b1g$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org> <vs41ap$n43$1@reader1.panix.com> <jwv7c4ajq11.fsf-monnier+comp.arch@gnu.org>
Injection-Date: Thu, 27 Mar 2025 18:34:00 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="11312"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 2076
Lines: 29

In article <jwv7c4ajq11.fsf-monnier+comp.arch@gnu.org>,
Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>>The illustrated code is using 6 participating cache lines.
>>>Where local variables are kept (stack, registers) does not
>>>count against the tally of participating cache lines.
>>
>> Huh.  How would this handle something like an MCS lock, where
>> the lock node may be on a stack, though accessible globally in
>> some virtual address space?
>
>ESM doesn't distinguish the stack from other places.  It just doesn't
>pay attention to memory accesses that aren't marked specially.  So, if
>you lock is on the stack it will still work, as long as you use
>`esmLOCKload` to read it.

Ah, I see.  Ok, that makes more sense.

>> Again, not what I was asking.  I'm trying to understand what you
>> meant when you talked about disappearing locks.
>
>He was talking about the conceptual lock used internally by the CPU
>to implement an ESM event, that gives their name to `esmLOCK*`.
>I.e. the same kind of lock used in other CPUs to implement LL/SC and
>that gives its name to "load locked" (tho it's also sometimes named
>"load linked").

Ok.  Thanks, Stefan.

	- Dan C.