On Wed Aug 23 17:19:46 2023 +0000, Zebediah Figura wrote:
i am unsure about this one. if the thread that got through is
de-scheduled in between the cmpxchgs, wouldn't all the spinning threads preventing it from being scheduled again in a timely manner? I'm afraid I'm not familiar enough with kernel scheduling to know the answer to this one. It's worth pointing out, though, that RtlWaitOnAddress() has its own spinlock. If there's more than two threads trying to concurrently add to the list, they're going to run into that spinlock anyway.
does `RtlWaitOnAddress` not have a short busy waiting loop?
It does not. Perhaps it should; I don't know, but given how much effort it took to get that function correct and performant, I'm wary of touching it.
Should it? Busy waits are a big issue already when apps do that themselves, shouldn't we avoid just any busy waits and heuristics around that (apart from locking something which is virtually guaranteed not to result in a real wait)?
Not related to this aspect, but I think the current implementation has a different issue with spinlock around control structures. Unless I am missing anything here, if we get SIGUSR for system APC while holding that lock, and that system APC will suspend the thread, the whole process will get locked up. I think this is a very unlikely condition so we are probably not hitting this in practices. Not sure which is a good way out of here, but if there are any ideas...