Many c++ programmers perfer to micro-manage bus cycles. That's why we use c++ instead of a HLL to begin with. XTL has several spin lock varations and uses similar locking techniques in some of the concurrent algorithms. Spin locks are very simple locking primitives and there's often confusion about when they're necessary or beneficial. Here's some guidelines on proper spin lock usage. These are general guidelines and there's always exceptions. If you're unsure about whether a spin lock is preferable to a kernel primitive then these guidelines will probably be right for the situation.

Don't hold a spin lock while performing an I/O operation. If the algorithm needs to perform I/O (disk, screen, printer, network, etc.) then use a kernel primitive. With the exception of heavy computationally intensive applications then largest application performance bottleneck is typically I/O operations. The processors typically take a vacation while I/O is in progress and since the kernel manages resource cooperation it will have better mechanisms to suspend and resume waiting threads. Some systems such as Windows have native locking primitives specifically for I/O waiting that can give a good performance boost over generic locking primitives. But, in general, any kernel lock will be preferable to spin locks while waiting for I/O.

Don't mix thread priorities with spin locks. Spin locks are for very fine-grain lock control and it's typically not appropriate to use with low priority threads. You probably don't want to starve a higher priority thread while a lower priority thread is holding a spin lock.

Don't hold a spin lock for long periods of time. If the thread is going to hold a lock for more than a few instructions then a kernel locking primitive is preferable.

Don't use spin locks on single core systems. Single core systems are hard to find these days outside the embedded world. This was a bigger issue in the post hyper-threading days but it also applied to applications with single core affinity on a multi-core system. If an application is going to run on a single core then a spin lock is almost never appropriate in user space. Use a native kernel locking primitive.

There's a narrow space where spin locks are appropriate. In general, use them on multi-core systems where other cores are only blocked for a few instructions. Spin locks are beneficial over kernel locks when the chances for a lock contention are very low or rarely happen. If the chance for contention is very low and a kernel lock is used then there is a good potential for wasted cycles because the kernel primitives are more costly. They're also preferable over kernel locks when the cost for performing the exclusive operations is lower than the cost of performing a task switch. Even when the chances of contention are high to moderate there can be a good performance boost when they lock is exclusively held for only a few instructions. In days past, a pre-emptive kernel could accomplish a task switch in no fewer than 100 or so instructions. I don't have metrics for modern kernels but presumably it's more since they're more complicated. If the lock will be held for a shorter duration than required to perform a task switch using a kernel primitive then a spin lock is probably a good choice.