1mutex(5) Standards, Environments, and Macros mutex(5)
2
6 mutex - concepts relating to mutual exclusion locks
7
9 Mutual exclusion locks (mutexes) prevent multiple threads from simulta‐
10 neously executing critical sections of code which access shared data
11 (that is, mutexes are used to serialize the execution of threads). All
12 mutexes must be global. A successful call to acquire a mutex will cause
13 another thread that is also trying to lock the same mutex to block
14 until the owner thread unlocks the mutex.
15 Mutexes can synchronize threads within the same process or in other
18 processes. Mutexes can be used to synchronize threads between processes
19 if the mutexes are allocated in writable memory and shared among the
20 cooperating processes (see mmap(2)), and have been initialized for this
21 task.
22 The following table lists mutex functions and the actions they perform.
25 ┌───────────────────────┬───────────────────────────────────┐
30 │ FUNCTION │ ACTION │
31 ├───────────────────────┼───────────────────────────────────┤
32 │mutex_init │ Initialize a mutex. │
33 │mutex_destroy │ Destroy a mutex. │
34 │mutex_lock │ Lock a mutex. │
35 │mutex_trylock │ Attempt to lock a mutex. │
36 │mutex_unlock │ Unlock a mutex. │
37 │pthread_mutex_init │ Initialize a mutex. │
38 │pthread_mutex_destroy │ Destroy a mutex. │
39 │pthread_mutex_lock │ Lock a mutex. │
40 │pthread_mutex_trylock │ Attempt to lock a mutex. │
41 │pthread_mutex_unlock │ Unlock a mutex. │
42 └───────────────────────┴───────────────────────────────────┘
43 Initialization
45 Mutexes are either intra-process or inter-process, depending upon the
46 argument passed implicitly or explicitly to the initialization of that
47 mutex. A statically allocated mutex does not need to be explicitly ini‐
48 tialized; by default, a statically allocated mutex is initialized with
49 all zeros and its scope is set to be within the calling process.
50 For inter-process synchronization, a mutex needs to be allocated in
53 memory shared between these processes. Since the memory for such a
54 mutex must be allocated dynamically, the mutex needs to be explicitly
55 initialized with the appropriate attribute that indicates inter-process
56 use.
57 Locking and Unlocking
59 A critical section of code is enclosed by a call to lock the mutex and
60 the call to unlock the mutex to protect it from simultaneous access by
61 multiple threads. Only one thread at a time may possess mutually exclu‐
62 sive access to the critical section of code that is enclosed by the
63 mutex-locking call and the mutex-unlocking call, whether the mutex's
64 scope is intra-process or inter-process. A thread calling to lock the
65 mutex either gets exclusive access to the code starting from the suc‐
66 cessful locking until its call to unlock the mutex, or it waits until
67 the mutex is unlocked by the thread that locked it.
68 Mutexes have ownership, unlike semaphores. Only the thread that locked
71 a mutex, (that is, the owner of the mutex), should unlock it.
72 If a thread waiting for a mutex receives a signal, upon return from the
75 signal handler, the thread resumes waiting for the mutex as if there
76 was no interrupt.
77 Caveats
79 Mutexes are almost like data - they can be embedded in data structures,
80 files, dynamic or static memory, and so forth. Hence, they are easy to
81 introduce into a program. However, too many mutexes can degrade perfor‐
82 mance and scalability of the application. Because too few mutexes can
83 hinder the concurrency of the application, they should be introduced
84 with care. Also, incorrect usage (such as recursive calls, or violation
85 of locking order, and so forth) can lead to deadlocks, or worse, data
86 inconsistencies.
87
89 See attributes(5) for descriptions of the following attributes:
90 ┌─────────────────────────────┬─────────────────────────────┐
95 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
96 ├─────────────────────────────┼─────────────────────────────┤
97 │MT-Level │MT-Safe │
98 └─────────────────────────────┴─────────────────────────────┘
99
101 mmap(2), shmop(2), mutex_destroy(3C), mutex_init(3C), mutex_lock(3C),
102 mutex_trylock(3C), mutex_unlock(3C), pthread_create(3C),
103 pthread_mutex_destroy(3C), pthread_mutex_init(3C),
104 pthread_mutex_lock(3C), pthread_mutex_trylock(3C),
105 pthread_mutex_unlock(3C), pthread_mutexattr_init(3C), attributes(5),
106 standards(5)
107
109 In the current implementation of threads, pthread_mutex_lock(),
110 pthread_mutex_unlock(), mutex_lock() mutex_unlock(), pthread_mutex_try‐
111 lock(), and mutex_trylock() do not validate the mutex type. Therefore,
112 an uninitialized mutex or a mutex with an invalid type does not return
113 EINVAL. Interfaces for mutexes with an invalid type have unspecified
114 behavior.
115 By default, if multiple threads are waiting for a mutex, the order of
118 acquisition is undefined.
119 The system does not support multiple mappings to the same logical synch
122 object if it is initialized as process-private (USYNC_THREAD for
123 Solaris, PTHREAD_PROCESS_PRIVATE for POSIX). If you need to mmap(2)a
124 synch object to different locations within the same address space, then
125 the synch object should be initialized as a shared object
126 (USYNC_PROCESS for Solaris, PTHREAD_PROCESS_SHARED for POSIX).
127SunOS 5.11 5 Jun 2007 mutex(5)