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: Tue, 25 Mar 2025 12:23:33 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: Injection-Date: Tue, 25 Mar 2025 12:23:33 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="6180"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Bytes: 8293 Lines: 173 In article , MitchAlsup1 wrote: >On Mon, 24 Mar 2025 23:45:49 +0000, Dan Cross wrote: >> In article , >> MitchAlsup1 wrote: >>>[snip] >>>My 66000 ATOMIC stuff is designed such that if control has to leave >>>the ATOMIC event, all HW knowledge of being in that event disappears >>>and IP is modified (prior to control transfer) such that upon return >>>SW knows the event failed (or never started), and that no update of >>>participating data in the event ever becomes visible. >>> >>>HW can do this with address-based events, but not with data-based >>>events. LDL-STC are address-based events used to manipulate data- >>>based events. Mine just allow more LDs and STs in the event than 1. >>> >>>So, if you want the property whereby the lock disappears on any >>>control transfer out of the event {exception, interrupt, SVC, SVR, ...}; >>>then you want to use my ATOMIC stuff; otherwise, you can use the >>>normal ATOMIC primitives everyone and his brother provide. >> >> I definitely do Not want that property. Having a lock >> "disappear" on delivery of an interrupt seems like it would be a >> great way to introduce silent corruption. > >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. > >Nothing gets lost. Perhaps we're not clear on what a "lock" is. Here, I'm referring to a mutual exclusion primitive that I use to protect entry into a critical section. You seem to be talking about something else. >{{Perhaps disappear was a poorly chosen word.}} > >> If your atomic primitives are not sufficient to cover an entire >> critical section, as I believe we have established, and are >> mostly intended to be used for building concurrency primitives >> like locks, then I expect that software would take the lock, see >> that it succeeded, and enter the critical section. >> >> If at that >> point the lock were silently discarded on receipt of an >> interrupt, > >At this point your thread in not IN the critical section !! Why not? I successfully acquired a lock, no? What else do you propose I must do to enter the critical section? >The closest you can be is at the first instruction beginning >an ATOMIC event (the never happened case) or you can also >be at the point where you KNOW that some other interfered >with your actions, and that they saw a completely consistent >state--now it is your turn (again) observing a completely >consistent but new state. Here's a bit of my earlier message that didn't get quoted in your reply: |If, on the other hand, the atomic primitives are just meant for |the spin loop, then I don't really see how that's all that |useful compared to LL/SC. And you still need some way to ensure |that the critical section is not interrupted. It seems like you're saying that the "ATOMIC event" is just for the spin loop. >> then potentially some other thread could subsequently >> take the lock, > >Since you are not in the critical section, you don't care. >No critical data has been modified, there is no inconsistent >state to be observed; and YOUR Instruction Pointer is not >pointing into instructions within the ATOMIC event !! This seems to be predicated on something that you understand about this mechanism that you've proposed, but haven't quite explained (or perhaps that I haven't understood). So again, I ask my question, how do I get into the critical section? Given the text quoted above from my last reply, what is the utility of these atomic events vis that goal? It sounds like you're saying that I can use them to implement a traditional spin lock. But then how are they better than a "normal" atomic CAS? You mention respecting priority and in particular avoiding inversion, but I don't think that's actually true: consider some critical section, where I cannot yield the CPU to another thread, even one running at higher priority, since I'm manipulating some data structure and it is important that that data structure not be in an intermediate state when I get switched away from; this strongly implies that I use these atomic primitives to build the sort of lock where I set some _other_ datum, not the "lock" manipulated in the atomic event, to indicate that I'm in the critical section: but if that's the case, then what prevents some other, higher priority thread, from attempting to enter the critical section _when I'm in it_, but not when I'm racing on the lock? E.g., this sequence of events: Thread A (lo pri) Thread B (hi pri) -------- -------- Atomic lock Observe success Acquire mutex Unlock Atomic Lock Observe success Observe that mutex is already set Unlock Now what? >> enter the critical section, and observe a data >> structure in an inconsistent state (leading to a crash in the >> best case). > >There is no inconsistent state--in rather the same way a core backs >up a branch mispredict, the core backs up the ATOMIC event to appear >as if it never even started !! We've already established that this cannot cover all use cases. See my example of popping off of a queue and inserting into an ordered list. >> This is precisely the sort of thing we build mutual >> exclusion primitives to wrap around critical sections to avoid. > >And also why those primitives give rise to priority inversion >and lock-starvation. But this mechanism is insufficient to actually address those problems in anything but the most limited ways. See the example above. Moreover, those are problems that are well understood and are successfully mitigated in real world systems. I do not see any evidence that they are sufficiently problematic supporting the introduction of a brand new mechanism with poorly understood behavior and what seems like very complex semantics. >> If, on the other hand, the atomic primitives are just meant for >> the spin loop, then I don't really see how that's all that >> useful compared to LL/SC. > >Any number of respected people have ask for a pipelined LL-SC; >where one can LL multiple datums and later SC multiple datums. >This is what ESM can provide. Who are these folks and have any of them chimed in on this proposal? It seems like you've gone far beyond "pipelined LL-SC" and introduced notions of threads and priorities that interact with that in complex and, frankly, undesirable ways. >> And you still need some way to ensure >> that the critical section is not interrupted. > >Just a way to detect if it happened; and if it happens; >means to back upto a point where it does not matter if >interference happened "right there"--that is: outside of >a critical section. This is based on the fallacious assumption that that is possible in the general case. I think I have shown that it is not. - Dan C.