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: References: <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.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 , Stefan Monnier 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.