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)?
Well, the question is whether that wait should be made "hybrid", i.e. try for some small number of cycles before going to sleep. That may be a bit different from a typical busy wait.
It is worth mentioning, though, that if the wait *is* made hybrid, a subsequent wake will leave a buffered thread-ID alert, which may waste time.
[I can't imagine how Windows thought it was a good idea to implement futexes like this. Then again, maybe they figured out some magic faster implementation that I couldn't figure out.]
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...
Yes. It won't deadlock, because a system APC should only execute system code, but it will leave the other thread spinning. Unfortunately I don't think this is avoidable, but if anyone *does* know a way to code a wait queue that is lock-free, fair, supports timeouts, and doesn't allocate, I would love to hear it.