As an example of where you might use a user space spinlock, consider:
If you have:
… a multithreaded process with shared resources that need locks
… and for the uncontested case your spinlock is much faster than your next fastest lock
… and you have resources for which the probability of a contested access is very close to zero
… and the locks are only held briefly (relative to compute quantum) (especially if they are held shorter than thread context switch)
You may find that the speed gained by using the spinlock is a win even if once in a while you end up burning your compute quantum because a thread got suspended holding a spinlock.
I agree with this assessment. Where the probability of collision is low, and spins are in that case of short duration anyway, and especially if test and set intrinsics are available, spin locks in userspace can be very valuable. They also, besides saving scheduler cycles, require only a common word access, even while that implicates barriers and cache lines.
If you have:
… a multithreaded process with shared resources that need locks
… and for the uncontested case your spinlock is much faster than your next fastest lock
… and you have resources for which the probability of a contested access is very close to zero
… and the locks are only held briefly (relative to compute quantum) (especially if they are held shorter than thread context switch)
You may find that the speed gained by using the spinlock is a win even if once in a while you end up burning your compute quantum because a thread got suspended holding a spinlock.