It absolutely is, which is why the benchmarks posted should not be taken seriously.
Some environments don't have a scheduler or a "user-space", and so this implementation can suffice, but the problem with this post is that all of the testing and benchmarking are done in user-space, and hence the metrics are not very meaningful.
No. You can configure the kernel run with a different scheduling policy and pretty much prevent preemption. You can even move IO interrupt handlers to other cores to really ensure you have the core.
I've seen things like that in industrial control systems. I think some high-performance networking setups also do things like that, doing almost everything in user-space, actively polling for packets from the hardware.
Another example are OS-bypassing workloads which are tail-latency sensitive. They will prefer to avoid any OS involvement and take charge of everything in user space.
It's nonsense to do this when you can be preempted. But you can run one thread per core and avoid preemption. You can tune the linux kernel to avoid almost all preemption, due to TLB shootdowns etc: https://rigtorp.se/low-latency-guide/
It depends. In a general purpose OS without scheduler trickery one would need at least some backoff & yielding syscall. And it's hugely workload dependent.
But more importantly, even with kernel backed waiting (e.g. using futexes) some userspace spinning can be important for performance. And then pretty much all the concerns from the spinlock apply there as well.
Preemption sure is non-deterministic from POV of the thread. But what's the point of it anyway? It's not like you handle HW interrupts in user-space and need to wait for some value in memory mapped register.
