1
by Francesco Paolo Lovergine
rules: linking manpages-posix not manpages. |
1 |
.\" Copyright (c) 2001-2003 The Open Group, All Rights Reserved |
2
by Francesco Paolo Lovergine
* Alligned to linux main manpages edition. |
2 |
.TH "PTHREAD_MUTEX_LOCK" P 2003 "IEEE/The Open Group" "POSIX Programmer's Manual" |
1
by Francesco Paolo Lovergine
rules: linking manpages-posix not manpages. |
3 |
.\" pthread_mutex_lock |
4 |
.SH NAME |
|
5 |
pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock \-
|
|
6 |
lock and unlock a mutex |
|
7 |
.SH SYNOPSIS |
|
8 |
.LP
|
|
9 |
\fB#include <pthread.h>
|
|
10 |
.br
|
|
11 |
.sp
|
|
12 |
int pthread_mutex_lock(pthread_mutex_t *\fP\fImutex\fP\fB); |
|
13 |
.br
|
|
14 |
int pthread_mutex_trylock(pthread_mutex_t *\fP\fImutex\fP\fB); |
|
15 |
.br
|
|
16 |
int pthread_mutex_unlock(pthread_mutex_t *\fP\fImutex\fP\fB); \fP |
|
17 |
\fB
|
|
18 |
.br
|
|
19 |
\fP
|
|
20 |
.SH DESCRIPTION |
|
21 |
.LP
|
|
22 |
The mutex object referenced by \fImutex\fP shall be locked by calling |
|
23 |
\fIpthread_mutex_lock\fP(). If the mutex is already |
|
24 |
locked, the calling thread shall block until the mutex becomes available. |
|
25 |
This operation shall return with the mutex object |
|
26 |
referenced by \fImutex\fP in the locked state with the calling thread |
|
27 |
as its owner. |
|
28 |
.LP
|
|
29 |
If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall |
|
30 |
not be provided. Attempting to relock the mutex causes |
|
31 |
deadlock. If a thread attempts to unlock a mutex that it has not locked |
|
32 |
or a mutex which is unlocked, undefined behavior |
|
33 |
results. |
|
34 |
.LP
|
|
35 |
If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking |
|
36 |
shall be provided. If a thread attempts to relock a mutex |
|
37 |
that it has already locked, an error shall be returned. If a thread |
|
38 |
attempts to unlock a mutex that it has not locked or a mutex |
|
39 |
which is unlocked, an error shall be returned. |
|
40 |
.LP
|
|
41 |
If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex shall |
|
42 |
maintain the concept of a lock count. When a thread |
|
43 |
successfully acquires a mutex for the first time, the lock count shall |
|
44 |
be set to one. Every time a thread relocks this mutex, the |
|
45 |
lock count shall be incremented by one. Each time the thread unlocks |
|
46 |
the mutex, the lock count shall be decremented by one. When |
|
47 |
the lock count reaches zero, the mutex shall become available for |
|
48 |
other threads to acquire. If a thread attempts to unlock a mutex |
|
49 |
that it has not locked or a mutex which is unlocked, an error shall |
|
50 |
be returned. |
|
51 |
.LP
|
|
52 |
If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively |
|
53 |
lock the mutex results in undefined behavior. Attempting |
|
54 |
to unlock the mutex if it was not locked by the calling thread results |
|
55 |
in undefined behavior. Attempting to unlock the mutex if it |
|
56 |
is not locked results in undefined behavior. |
|
57 |
.LP
|
|
58 |
The \fIpthread_mutex_trylock\fP() function shall be equivalent to |
|
59 |
\fIpthread_mutex_lock\fP(), except that if the mutex object |
|
60 |
referenced by \fImutex\fP is currently locked (by any thread, including |
|
61 |
the current thread), the call shall return immediately. If |
|
62 |
the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex is currently |
|
63 |
owned by the calling thread, the mutex lock count shall be |
|
64 |
incremented by one and the \fIpthread_mutex_trylock\fP() function |
|
65 |
shall immediately return success. |
|
66 |
.LP
|
|
67 |
The \fIpthread_mutex_unlock\fP() function shall release the mutex |
|
68 |
object referenced by \fImutex\fP. \ The manner |
|
69 |
in which a mutex is released is dependent upon the mutex's type attribute. |
|
70 |
If there are threads blocked on the mutex object referenced by \fImutex\fP |
|
71 |
when \fIpthread_mutex_unlock\fP() is |
|
72 |
called, resulting in the mutex becoming available, the scheduling |
|
73 |
policy shall determine which thread shall acquire the mutex. |
|
74 |
.LP
|
|
75 |
(In the case of PTHREAD_MUTEX_RECURSIVE mutexes, the mutex shall become |
|
76 |
available when the count reaches zero and the calling |
|
77 |
thread no longer has any locks on this mutex.) |
|
78 |
.LP
|
|
79 |
If a signal is delivered to a thread waiting for a mutex, upon return |
|
80 |
from the signal handler the thread shall resume waiting |
|
81 |
for the mutex as if it was not interrupted. |
|
82 |
.SH RETURN VALUE |
|
83 |
.LP
|
|
84 |
If successful, the \fIpthread_mutex_lock\fP() and \fIpthread_mutex_unlock\fP() |
|
85 |
functions shall return zero; otherwise, an |
|
86 |
error number shall be returned to indicate the error. |
|
87 |
.LP
|
|
88 |
The \fIpthread_mutex_trylock\fP() function shall return zero if a |
|
89 |
lock on the mutex object referenced by \fImutex\fP is |
|
90 |
acquired. Otherwise, an error number is returned to indicate the error. |
|
91 |
.SH ERRORS |
|
92 |
.LP
|
|
93 |
The \fIpthread_mutex_lock\fP() and \fIpthread_mutex_trylock\fP() functions |
|
94 |
shall fail if: |
|
95 |
.TP 7 |
|
96 |
.B EINVAL |
|
97 |
The \fImutex\fP was created with the protocol attribute having the |
|
98 |
value PTHREAD_PRIO_PROTECT and the calling thread's |
|
99 |
priority is higher than the mutex's current priority ceiling. |
|
100 |
.sp
|
|
101 |
.LP
|
|
102 |
The \fIpthread_mutex_trylock\fP() function shall fail if: |
|
103 |
.TP 7 |
|
104 |
.B EBUSY |
|
105 |
The \fImutex\fP could not be acquired because it was already locked. |
|
106 |
.sp
|
|
107 |
.LP
|
|
108 |
The \fIpthread_mutex_lock\fP(), \fIpthread_mutex_trylock\fP(), and |
|
109 |
\fIpthread_mutex_unlock\fP() functions may fail if: |
|
110 |
.TP 7 |
|
111 |
.B EINVAL |
|
112 |
The value specified by \fImutex\fP does not refer to an initialized |
|
113 |
mutex object. |
|
114 |
.TP 7 |
|
115 |
.B EAGAIN |
|
116 |
The mutex could not be acquired because the maximum number of recursive |
|
117 |
locks for \fImutex\fP has been exceeded. |
|
118 |
.sp
|
|
119 |
.LP
|
|
120 |
The \fIpthread_mutex_lock\fP() function may fail if: |
|
121 |
.TP 7 |
|
122 |
.B EDEADLK |
|
123 |
The current thread already owns the mutex. |
|
124 |
.sp
|
|
125 |
.LP
|
|
126 |
The \fIpthread_mutex_unlock\fP() function may fail if: |
|
127 |
.TP 7 |
|
128 |
.B EPERM |
|
129 |
The current thread does not own the mutex. |
|
130 |
.sp
|
|
131 |
.LP
|
|
132 |
These functions shall not return an error code of [EINTR]. |
|
133 |
.LP
|
|
134 |
\fIThe following sections are informative.\fP |
|
135 |
.SH EXAMPLES |
|
136 |
.LP
|
|
137 |
None. |
|
138 |
.SH APPLICATION USAGE |
|
139 |
.LP
|
|
140 |
None. |
|
141 |
.SH RATIONALE |
|
142 |
.LP
|
|
143 |
Mutex objects are intended to serve as a low-level primitive from |
|
144 |
which other thread synchronization functions can be built. As |
|
145 |
such, the implementation of mutexes should be as efficient as possible, |
|
146 |
and this has ramifications on the features available at the |
|
147 |
interface. |
|
148 |
.LP
|
|
149 |
The mutex functions and the particular default settings of the mutex |
|
150 |
attributes have been motivated by the desire to not |
|
151 |
preclude fast, inlined implementations of mutex locking and unlocking. |
|
152 |
.LP
|
|
153 |
For example, deadlocking on a double-lock is explicitly allowed behavior |
|
154 |
in order to avoid requiring more overhead in the basic |
|
155 |
mechanism than is absolutely necessary. (More "friendly" mutexes that |
|
156 |
detect deadlock or that allow multiple locking by the same |
|
157 |
thread are easily constructed by the user via the other mechanisms |
|
158 |
provided. For example, \fIpthread_self\fP() can be used to record |
|
159 |
mutex ownership.) Implementations might also |
|
160 |
choose to provide such extended features as options via special mutex |
|
161 |
attributes. |
|
162 |
.LP
|
|
163 |
Since most attributes only need to be checked when a thread is going |
|
164 |
to be blocked, the use of attributes does not slow the |
|
165 |
(common) mutex-locking case. |
|
166 |
.LP
|
|
167 |
Likewise, while being able to extract the thread ID of the owner of |
|
168 |
a mutex might be desirable, it would require storing the |
|
169 |
current thread ID when each mutex is locked, and this could incur |
|
170 |
unacceptable levels of overhead. Similar arguments apply to a |
|
171 |
\fImutex_tryunlock\fP operation. |
|
172 |
.SH FUTURE DIRECTIONS |
|
173 |
.LP
|
|
174 |
None. |
|
175 |
.SH SEE ALSO |
|
176 |
.LP
|
|
177 |
\fIpthread_mutex_destroy\fP() , \fIpthread_mutex_timedlock\fP() , |
|
178 |
the Base Definitions volume of |
|
179 |
IEEE\ Std\ 1003.1-2001, \fI<pthread.h>\fP |
|
180 |
.SH COPYRIGHT |
|
181 |
Portions of this text are reprinted and reproduced in electronic form |
|
182 |
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology |
|
183 |
-- Portable Operating System Interface (POSIX), The Open Group Base |
|
184 |
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of |
|
185 |
Electrical and Electronics Engineers, Inc and The Open Group. In the |
|
186 |
event of any discrepancy between this version and the original IEEE and |
|
187 |
The Open Group Standard, the original IEEE and The Open Group Standard |
|
188 |
is the referee document. The original Standard can be obtained online at |
|
189 |
http://www.opengroup.org/unix/online.html . |