On Tue Aug 22 23:51:39 2023 +0000, Zebediah Figura wrote:
I worry about the prospect of making this a futex wait, because as cheap as futexes are, we are in an extremely hot path here. Considering that what we're racing against should be two consecutive cmpxchg instructions, with no intervening calculations or memory accesses, I think spinning may be the right answer here. I don't know if that means that we explicitly spin until the lock changes, or we just return FALSE and go through srwlock_wait() again.
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?
does `RtlWaitOnAddress` not have a short busy waiting loop?