A spinlock can be conditionally faster than a lock with uses futex, but it doesn't scale. Futex is really meant to provide an efficient way to block and unblock threads. One could use FUTEX_LOCK_PI to have it actually implement a lock, but that's a separate argument/edge-case.

I don’t think it was particularly fair. The reason is probably that the question was poorly formed: it’s like asking how much of a performance benefit an application gets from "read" (not exactly like that; you could implement locking without futexes, it would just typically be worse, potentially by a lot, and doesn’t really work in as many cases). It also isn’t really the topic which should really be the new api rather than current futexes, though that sort of thinking doesn’t really stop anyone.

A better question to ask might have been for examples of cases improved by the new api. (Or rather by the new features that can be added thanks to the new api). An example improvement is that by having smaller futexes (8-bit instead of 32-bit) you can fit more in a cache line which could matter for some applications, I guess.