Question

I’m not quite sure if it’s safe to spin on a volatile variable in user-mode threads, to implement a light-weight spin_lock, I looked at the tbb source code, tbb_machine.h:170,

//! Spin WHILE the value of the variable is equal to a given value
/** T and U should be comparable types. */
template<typename T, typename U>
void spin_wait_while_eq( const volatile T& location, U value ) {
    atomic_backoff backoff;
    while( location==value ) backoff.pause();
}

And there is no fences in atomic_backoff class as I can see. While from other user-mode spin_lock implementation, most of them use CAS (Compare and Swap).

Answer 1

Tricky. I’d say that in theory, this code isn’t safe. If there are no memory barriers then the data accesses you’re guarding could be moved across the spinlock. However, this would only be done if the compiler inlined very aggressively, and could see a purpose in this reordering.

Perhaps Intel simply determined that this code works on all current compilers, and that even though a compiler could theoretically perform transformations that’d break this code, those transformations wouldn’t speed up the program, and so compilers probably won’t do it.

Another possibility is that this code is only used on compilers that implicitly implement memory barriers around volatile accesses. Microsoft’s Visual C++ compiler (2005 and later) does this. Have you checked if this is wrapped in an #ifdef block or similar, applying this implementation only on compilers where volatile use memory barriers?