In terms of "Fast Queue Spinlocks", Michel Lespinasse of Google wrote:
I understand that in the past, such proposals have been defeated by two main arguments:For demonstrating his queue spinlock proposal, Lespinasse converted the IPC object spinlock and network qdisc busylock to the new interface. He's published the six patches to the Linux kernel mailing list for comments and suggestions by fellow Linux kernel developers. He has also provided some preliminary benchmarks of Fast Queue Spinlocks.
- That it is generally preferable to use smart algorithms that can avoid lock contention altogether, rather than spending effort on the lock itself to deal with the contention, and
- That the lightly contended case matters more to real workloads than the highly contended case, and that the most well known scalable spinlock algorithms tend to be relatively slow in the lightly contended case.
I am hoping for a different result this time around based on the following counter-arguments:
- There are situations where the lock contention is directly driven by user events, with little opportunity to reduce it in-kernel. One example might be when the user requests that the kernel acquires or releases semaphores on its behalf using sysv IPC APIs - it is hard to imagine how the kernel could mitigate spinlock contention issues for the user.
- More importantly, the queue spinlock implementation I am proposing seems to behave well both under light and heavy contention. It uses one single atomic operation on the lock side, and (on x86) only a single memory store on the unlock side, with fairly short code sections on both sides, and just compares well with the ticket spinlock on the benchmarks I have tried. To be clear, I am not proposing replacing every ticket spinlock usage with queue spinlocks; I am only proposing to have both APIs available and pick them as appropriate for each use case.
The patch-set and discussion about Fast Queue Spinlocks for the Linux kernel can be found here.