usr/src/man/man5/mutex.5

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