Зависит от реализации, pthread_spin_lock официально не гарантированно остается в пользовательском пространстве. На практике в системах, которые имеют инструкцию CAS (то есть в большинстве обычных систем SMP), это часто имеет место.
Здесь приведены ссылки на реализации glib c для x86 , x86-64 , ia64 , sparc32 , sparc64 , PP C, SH4 и общий случай , все основаны на CAS l oop.
Точно так же нет гарантии, что конкретная реализация std::atomic не будет go для ядра, но на практике, особенно когда std::atomic<T>::is_lock_free() возвращает true, оно будет реализовано в пользовательском пространстве с помощью инструкций atomi c.
Обратите внимание также, что в современном Linux pthread_mutex_lock реализовано используя futex, то есть «мьютекс пространства пользователя», он остается в пространстве пользователя в неконтролируемом случае. malloc будет go ядру, только если есть конфликт или когда нужно зарезервировать больше виртуальной памяти.
Сказав это, является ли спин-блокировка правильным выбором для синхронизации, это более широкий вопрос это зависит от большего количества факторов, которые просто системные вызовы. Как объяснено в этот вопрос , он полезен в реальных случаях SMP, когда конфликтующее состояние очень короткое. Большинство преимуществ производительности достигается за счет экономии на переключении контекста и планировании.
Некоторые реализации мьютекса (например, критическая секция Windows) являются гибридными: сначала они будут вращаться некоторое время и только после этого делегируются основанный на syscall замок.