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 still a busy wait, even a small one, involving interlocked memory access, and some guesses of what amount of spin is beneficial without having much of reliable data to decide on that. I think such solutions are also most often problematic in user space as what is small number and whether it make sense highly depends on app's workload and overall load.
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.
It will de-facto deadlock if system APC is going to suspend thread (as the lock is going to be held until thread is unsuspended which may be forever). If there is some other system APC it won't deadlock although lock all the SRW locks operation process wise for the time of execution.
I don't know if there is a viable lock-free wait queue solution, likely a dead end complexity-wise in practice. What I could think of is some indication of "uninterruptable" section with either some rollback procedure to be called from sigusr handler or delayed sigusr processing to be initiated after exiting the lock from the functions taking such a lock. Not great comlexity wise as well but probably technically feasible. Or, well, maybe at least indicating that the lock is taken and printing a fixme in signal handler for a start, so we at least know when we hit that in practice?