Section (3) pthread_spin_init
pthread_spin_init, pthread_spin_destroy — initialize or destroy a spin lock
Compile and link with
General note: Most programs should use mutexes instead of spin locks. Spin locks are primarily useful in conjunction with real-time scheduling policies. See NOTES.
function allocates any resources required for the use of the
spin lock referred to by
lock and initializes the lock
to be in the unlocked state. The
pshared argument must have one
of the following values:
The spin lock is to be operated on only by threads in the same process as the thread that calls
pthread_spin_init(). (Attempting to share the spin lock between processes results in undefined behavior.)
The spin lock may be operated on by any thread in any process that has access to the memory containing the lock (i.e., the lock may be in a shared memory object that is shared among multiple processes).
on a spin lock that has already been initialized results in
function destroys a previously initialized spin lock, freeing
any resources that were allocated for that lock. Destroying a
spin lock that has not been previously been initialized or
destroying a spin lock while another thread holds the lock
results in undefined behavior.
Once a spin lock has been destroyed, performing any
operation on the lock other than once more initializing it
results in undefined behavior.
On success, there functions return zero. On failure, they
return an error number. In the event that
pthread_spin_init() fails, the lock is not
pthread_spin_init() may fail
with the following errors:
The system has insufficient resources to initialize a new spin lock.
Insufficient memory to initialize the spin lock.
Support for process-shared spin locks is a POSIX option. The option is supported in the glibc implementation.
Spin locks should be employed in conjunction with
real-time scheduling policies (
SCHED_FIFO, or possibly
SCHED_RR). Use of spin locks with
nondeterministic scheduling policies such as
SCHED_OTHER probably indicates a design
mistake. The problem is that if a thread operating under such
a policy is scheduled off the CPU while it holds a spin lock,
then other threads will waste time spinning on the lock until
the lock holder is once more rescheduled and releases the
If threads create a deadlock situation while employing spin locks, those threads will spin forever consuming CPU time.
User-space spin locks are not applicable as a general locking solution. They are, by definition, prone to priority inversion and unbounded spin times. A programmer using spin locks must be exceptionally careful not only in the code, but also in terms of system configuration, thread placement, and priority assignment.
This page is part of release 5.04 of the Linux
man-pages project. A
description of the project, information about reporting bugs,
and the latest version of this page, can be found at
Copyright (c) 2017, Michael Kerrisk <mtk.manpagesgmail.com>
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Since the Linux kernel and libraries are constantly changing, this
manual page may be incorrect or out-of-date. The author(s) assume no
responsibility for errors or omissions, or for damages resulting from
the use of the information contained herein. The author(s) may not
have taken the same level of care in the production of this manual,
which is licensed free of charge, as they might when working
Formatted or processed versions of this manual, if unaccompanied by
the source, must acknowledge the copyright and authors of this work.