| blob | aafa52aa7aa427be412435f4fe492babc8797100 |
1 .\"
2 .\" Sun Microsystems, Inc. gratefully acknowledges The Open Group for
3 .\" permission to reproduce portions of its copyrighted documentation.
4 .\" Original documentation from The Open Group can be obtained online at
5 .\" http://www.opengroup.org/bookstore/.
6 .\"
7 .\" The Institute of Electrical and Electronics Engineers and The Open
8 .\" Group, have given us permission to reprint portions of their
9 .\" documentation.
10 .\"
11 .\" In the following statement, the phrase ``this text'' refers to portions
12 .\" of the system documentation.
13 .\"
14 .\" Portions of this text are reprinted and reproduced in electronic form
15 .\" in the SunOS Reference Manual, from IEEE Std 1003.1, 2004 Edition,
16 .\" Standard for Information Technology -- Portable Operating System
17 .\" Interface (POSIX), The Open Group Base Specifications Issue 6,
18 .\" Copyright (C) 2001-2004 by the Institute of Electrical and Electronics
19 .\" Engineers, Inc and The Open Group. In the event of any discrepancy
20 .\" between these versions and the original IEEE and The Open Group
21 .\" Standard, the original IEEE and The Open Group Standard is the referee
22 .\" document. The original Standard can be obtained online at
23 .\" http://www.opengroup.org/unix/online.html.
24 .\"
25 .\" This notice shall appear on any product containing this material.
26 .\"
27 .\" The contents of this file are subject to the terms of the
28 .\" Common Development and Distribution License (the "License").
29 .\" You may not use this file except in compliance with the License.
30 .\"
31 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
32 .\" or http://www.opensolaris.org/os/licensing.
33 .\" See the License for the specific language governing permissions
34 .\" and limitations under the License.
35 .\"
36 .\" When distributing Covered Code, include this CDDL HEADER in each
37 .\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
38 .\" If applicable, add the following below this CDDL HEADER, with the
39 .\" fields enclosed by brackets "[]" replaced with your own identifying
40 .\" information: Portions Copyright [yyyy] [name of copyright owner]
41 .\"
42 .\"
43 .\" Portions Copyright (c) 1995 IEEE All Rights Reserved.
44 .\" Copyright (c) 1998 Sun Microsystems, Inc. All Rights Reserved.
45 .\" Copyright (c) 2001, The IEEE and The Open Group. All Rights Reserved.
46 .\"
47 .TH MUTEX 5 "Jun 5, 2007"
48 .SH NAME
49 mutex \- concepts relating to mutual exclusion locks
50 .SH DESCRIPTION
51 .sp
52 .LP
53 Mutual exclusion locks (mutexes) prevent multiple threads from simultaneously
54 executing critical sections of code which access shared data (that is, mutexes
55 are used to serialize the execution of threads). All mutexes must be global. A
56 successful call to acquire a mutex will cause another thread that is also
57 trying to lock the same mutex to block until the owner thread unlocks the
58 mutex.
59 .sp
60 .LP
61 Mutexes can synchronize threads within the same process or in other processes.
62 Mutexes can be used to synchronize threads between processes if the mutexes are
63 allocated in writable memory and shared among the cooperating processes (see
64 \fBmmap\fR(2)), and have been initialized for this task.
65 .sp
66 .LP
67 The following table lists mutex functions and the actions they perform.
68 .sp
70 .sp
71 .TS
72 box;
73 c | c
74 l | l .
75 FUNCTION ACTION
76 _
77 \fBmutex_init\fR Initialize a mutex.
78 \fBmutex_destroy\fR Destroy a mutex.
79 \fBmutex_lock\fR Lock a mutex.
80 \fBmutex_trylock\fR Attempt to lock a mutex.
81 \fBmutex_unlock\fR Unlock a mutex.
82 \fBpthread_mutex_init\fR Initialize a mutex.
83 \fBpthread_mutex_destroy\fR Destroy a mutex.
84 \fBpthread_mutex_lock\fR Lock a mutex.
85 \fBpthread_mutex_trylock\fR Attempt to lock a mutex.
86 \fBpthread_mutex_unlock\fR Unlock a mutex.
87 .TE
89 .SS "Initialization"
90 .sp
91 .LP
92 Mutexes are either intra-process or inter-process, depending upon the argument
93 passed implicitly or explicitly to the initialization of that mutex. A
94 statically allocated mutex does not need to be explicitly initialized; by
95 default, a statically allocated mutex is initialized with all zeros and its
96 scope is set to be within the calling process.
97 .sp
98 .LP
99 For inter-process synchronization, a mutex needs to be allocated in memory
100 shared between these processes. Since the memory for such a mutex must be
101 allocated dynamically, the mutex needs to be explicitly initialized with the
102 appropriate attribute that indicates inter-process use.
103 .SS "Locking and Unlocking"
104 .sp
105 .LP
106 A critical section of code is enclosed by a call to lock the mutex and the call
107 to unlock the mutex to protect it from simultaneous access by multiple threads.
108 Only one thread at a time may possess mutually exclusive access to the critical
109 section of code that is enclosed by the mutex-locking call and the
110 mutex-unlocking call, whether the mutex's scope is intra-process or
111 inter-process. A thread calling to lock the mutex either gets exclusive access
112 to the code starting from the successful locking until its call to unlock the
113 mutex, or it waits until the mutex is unlocked by the thread that locked it.
114 .sp
115 .LP
116 Mutexes have ownership, unlike semaphores. Only the thread that locked a mutex,
117 (that is, the owner of the mutex), should unlock it.
118 .sp
119 .LP
120 If a thread waiting for a mutex receives a signal, upon return from the signal
121 handler, the thread resumes waiting for the mutex as if there was no interrupt.
122 .SS "Caveats"
123 .sp
124 .LP
125 Mutexes are almost like data - they can be embedded in data structures, files,
126 dynamic or static memory, and so forth. Hence, they are easy to introduce into
127 a program. However, too many mutexes can degrade performance and scalability of
128 the application. Because too few mutexes can hinder the concurrency of the
129 application, they should be introduced with care. Also, incorrect usage (such
130 as recursive calls, or violation of locking order, and so forth) can lead to
131 deadlocks, or worse, data inconsistencies.
132 .SH ATTRIBUTES
133 .sp
134 .LP
135 See \fBattributes\fR(5) for descriptions of the following attributes:
136 .sp
138 .sp
139 .TS
140 box;
141 c | c
142 l | l .
143 ATTRIBUTE TYPE ATTRIBUTE VALUE
144 _
145 MT-Level MT-Safe
146 .TE
148 .SH SEE ALSO
149 .sp
150 .LP
151 \fBmmap\fR(2), \fBshmop\fR(2), \fBmutex_destroy\fR(3C), \fBmutex_init\fR(3C),
152 \fBmutex_lock\fR(3C), \fBmutex_trylock\fR(3C), \fBmutex_unlock\fR(3C),
153 \fBpthread_create\fR(3C), \fBpthread_mutex_destroy\fR(3C),
154 \fBpthread_mutex_init\fR(3C), \fBpthread_mutex_lock\fR(3C),
155 \fBpthread_mutex_trylock\fR(3C), \fBpthread_mutex_unlock\fR(3C),
156 \fBpthread_mutexattr_init\fR(3C), \fBattributes\fR(5), \fBstandards\fR(5)
157 .SH NOTES
158 .sp
159 .LP
160 In the current implementation of threads, \fBpthread_mutex_lock()\fR,
161 \fBpthread_mutex_unlock()\fR, \fBmutex_lock()\fR \fBmutex_unlock()\fR,
162 \fBpthread_mutex_trylock()\fR, and \fBmutex_trylock()\fR do not validate the
163 mutex type. Therefore, an uninitialized mutex or a mutex with an invalid type
164 does not return \fBEINVAL\fR. Interfaces for mutexes with an invalid type have
165 unspecified behavior.
166 .sp
167 .LP
168 By default, if multiple threads are waiting for a mutex, the order of
169 acquisition is undefined.
170 .sp
171 .LP
172 The system does not support multiple mappings to the same logical synch object
173 if it is initialized as process-private (\fBUSYNC_THREAD\fR for Solaris,
174 \fBPTHREAD_PROCESS_PRIVATE\fR for POSIX). If you need to \fBmmap\fR(2)a synch
175 object to different locations within the same address space, then the synch
176 object should be initialized as a shared object (\fBUSYNC_PROCESS\fR for
177 Solaris, \fBPTHREAD_PROCESS_SHARED\fR for POSIX).