pthread_spin_init(3)

1pthread_spin_init(3)       Library Functions Manual       pthread_spin_init(3)
2
3
4

NAME

6       pthread_spin_init,  pthread_spin_destroy - initialize or destroy a spin
7       lock
8

LIBRARY

10       POSIX threads library (libpthread, -lpthread)
11

SYNOPSIS

13       #include <pthread.h>
14
15       int pthread_spin_init(pthread_spinlock_t *lock, int pshared);
16       int pthread_spin_destroy(pthread_spinlock_t *lock);
17
18   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
19
20       pthread_spin_init(), pthread_spin_destroy():
21           _POSIX_C_SOURCE >= 200112L
22

DESCRIPTION

24       General note: Most programs should use mutexes instead of  spin  locks.
25       Spin  locks are primarily useful in conjunction with real-time schedul‐
26       ing policies.  See NOTES.
27
28       The pthread_spin_init() function allocates any resources  required  for
29       the  use  of the spin lock referred to by lock and initializes the lock
30       to be in the unlocked state.  The pshared argument must have one of the
31       following values:
32
33       PTHREAD_PROCESS_PRIVATE
34              The  spin  lock is to be operated on only by threads in the same
35              process as the thread that calls pthread_spin_init().  (Attempt‐
36              ing  to  share  the spin lock between processes results in unde‐
37              fined behavior.)
38
39       PTHREAD_PROCESS_SHARED
40              The spin lock may be operated on by any thread  in  any  process
41              that  has  access  to  the memory containing the lock (i.e., the
42              lock may be in a shared memory object that is shared among  mul‐
43              tiple processes).
44
45       Calling  pthread_spin_init()  on a spin lock that has already been ini‐
46       tialized results in undefined behavior.
47
48       The pthread_spin_destroy() function destroys a  previously  initialized
49       spin  lock,  freeing  any  resources that were allocated for that lock.
50       Destroying a spin lock that has not been previously been initialized or
51       destroying  a  spin lock while another thread holds the lock results in
52       undefined behavior.
53
54       Once a spin lock has been destroyed, performing any  operation  on  the
55       lock  other than once more initializing it with pthread_spin_init() re‐
56       sults in undefined behavior.
57
58       The result  of  performing  operations  such  as  pthread_spin_lock(3),
59       pthread_spin_unlock(3), and pthread_spin_destroy() on copies of the ob‐
60       ject referred to by lock is undefined.
61

RETURN VALUE

63       On success, there functions return zero.  On failure,  they  return  an
64       error number.  In the event that pthread_spin_init() fails, the lock is
65       not initialized.
66

ERRORS

68       pthread_spin_init() may fail with the following errors:
69
70       EAGAIN The system has insufficient resources to initialize a  new  spin
71              lock.
72
73       ENOMEM Insufficient memory to initialize the spin lock.
74

STANDARDS

76       POSIX.1-2008.
77

HISTORY

79       glibc 2.2.  POSIX.1-2001.
80
81       Support for process-shared spin locks is a POSIX option.  The option is
82       supported in the glibc implementation.
83

NOTES

85       Spin locks should be employed in conjunction with real-time  scheduling
86       policies  (SCHED_FIFO,  or  possibly SCHED_RR).  Use of spin locks with
87       nondeterministic scheduling policies such as SCHED_OTHER probably indi‐
88       cates  a design mistake.  The problem is that if a thread operating un‐
89       der such a policy is scheduled off the CPU while it holds a spin  lock,
90       then  other threads will waste time spinning on the lock until the lock
91       holder is once more rescheduled and releases the lock.
92
93       If threads create a deadlock  situation  while  employing  spin  locks,
94       those threads will spin forever consuming CPU time.
95
96       User-space spin locks are not applicable as a general locking solution.
97       They are, by definition, prone to priority inversion and unbounded spin
98       times.  A programmer using spin locks must be exceptionally careful not
99       only in the code, but also in terms  of  system  configuration,  thread
100       placement, and priority assignment.
101