1.\" 2.\" Copyright (c) 1998 Berkeley Software Design, Inc. All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. Berkeley Software Design Inc's name may not be used to endorse or 13.\" promote products derived from this software without specific prior 14.\" written permission. 15.\" 16.\" THIS SOFTWARE IS PROVIDED BY BERKELEY SOFTWARE DESIGN INC ``AS IS'' AND 17.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 18.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 19.\" ARE DISCLAIMED. IN NO EVENT SHALL BERKELEY SOFTWARE DESIGN INC BE LIABLE 20.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 21.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 22.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 23.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 24.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 25.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 26.\" SUCH DAMAGE. 27.\" 28.\" from BSDI $Id: mutex.4,v 1.1.2.3 1998/04/27 22:53:13 ewv Exp $ 29.\" $FreeBSD$ 30.\" 31.Dd February 12, 2001 32.Dt MUTEX 9 33.Os 34.Sh NAME 35.Nm mutex , 36.Nm mtx_init , 37.Nm mtx_lock , 38.Nm mtx_lock_spin , 39.Nm mtx_lock_flags , 40.Nm mtx_lock_spin_flags , 41.Nm mtx_trylock , 42.Nm mtx_trylock_flags , 43.Nm mtx_unlock , 44.Nm mtx_unlock_spin , 45.Nm mtx_unlock_flags , 46.Nm mtx_unlock_spin_flags , 47.Nm mtx_destroy , 48.Nm mtx_owned , 49.Nm mtx_recursed , 50.Nm mtx_assert 51.Nd kernel synchronization primitives 52.Sh SYNOPSIS 53.Fd #include <sys/mutex.h> 54.Ft int 55.Fn mtx_init "struct mtx *mutex" "char *name" "int opts" 56.Ft void 57.Fn mtx_lock "struct mtx *mutex" 58.Ft void 59.Fn mtx_lock_spin "struct mtx *mutex" 60.Ft void 61.Fn mtx_lock_flags "struct mtx *mutex" "int flags" 62.Ft void 63.Fn mtx_lock_spin_flags "struct mtx *mutex" "int flags" 64.Ft int 65.Fn mtx_trylock "struct mtx *mutex" 66.Ft int 67.Fn mtx_trylock_flags "struct mtx *mutex" "int flags" 68.Ft void 69.Fn mtx_unlock "struct mtx *mutex" 70.Ft void 71.Fn mtx_unlock_spin "struct mtx *mutex" 72.Ft void 73.Fn mtx_unlock_flags "struct mtx *mutex" "int flags" 74.Ft void 75.Fn mtx_unlock_spin_flags "struct mtx *mutex" "int flags" 76.Ft void 77.Fn mtx_destroy "struct mtx *mutex" 78.Ft int 79.Fn mtx_owned "struct mtx *mutex" 80.Ft int 81.Fn mtx_recursed "struct mtx *mutex" 82.Ft void 83.Fn mtx_assert "struct mtx *mutex" "int what" 84.Sh DESCRIPTION 85Mutexes are the most basic and primary method of process synchronization. 86The major design considerations for mutexes are: 87.Bl -enum 88.It 89Acquiring and releasing uncontested mutexes should be as cheap 90as possible. 91.It 92They must have the information and storage space to support 93priority propagation. 94.It 95A process must be able to recursively acquire a mutex, 96provided that the mutex is initialized to support recursion. 97.El 98.Pp 99There are currently two flavors of mutexes, those that context switch 100when they block and those that do not. 101.Pp 102By default, 103.Dv MTX_DEF 104mutexes will context switch when they are already held. 105As a machine dependent optimization they may spin for some amount 106of time before context switching. 107It is important to remember that since a process may be preempted at any time, 108the possible context switch introduced by acquiring a mutex is guaranteed 109to not break anything that isn't already broken. 110.Pp 111Mutexes which do not context switch are 112.Dv MTX_SPIN 113mutexes. 114These should only be used to protect data shared with any devices that 115require non-preemptive interrupts, and low level scheduling code. 116In most/all architectures both acquiring and releasing of a 117uncontested spin mutex is more expensive than the same operation 118on a non spin mutex. 119In order to protect an interrupt service routine from blocking 120against itself all interrupts are blocked on a processor while 121holding a spin lock. 122It is permissible to hold multiple spin mutexes. 123In this case it is a required that they be released in the opposite 124order to that which they were acquired. 125.Pp 126Once a spin mutex has been acquired it is not permissible to acquire a 127blocking mutex. 128.Pp 129The storage needed to implement a mutex is provided by a 130.Vt struct mtx . 131In general this should be treated as an opaque object and 132referenced only with the mutex primitives. 133.Pp 134The 135.Fn mtx_init 136function must be used to initialize a mutex 137before it can be passed to 138.Fn mtx_lock . 139The 140.Fa name 141argument is used by the witness code 142to classify a mutex when doing checks of lock ordering. 143The pointer passed in as the 144.Fa name 145is saved rather than the data it points to. 146The data pointed to must remain stable 147until the mutex is destroyed. 148The 149.Fa opts 150argument is used to set the type of mutex. 151It may contain either 152.Dv MTX_DEF 153or 154.Dv MTX_SPIN 155but not both. 156Optionally, it may also contain the 157.Dv MTX_RECURSE 158bit, which signifies that the mutex will be allowed to recurse. 159It is not permissible to pass the same 160.Fa mutex 161to 162.Fn mtx_init 163multiple times without intervening calls to 164.Fn mtx_destroy . 165.Pp 166The 167.Fn mtx_lock 168function acquires a 169.Dv MTX_DEF 170mutual exclusion lock 171on behalf of the currently running kernel thread. 172If another kernel thread is holding the mutex, 173the caller will be disconnected from the CPU 174until the mutex is available 175(i.e. it will sleep). 176.Pp 177The 178.Fn mtx_lock_spin 179function acquires a 180.Dv MTX_SPIN 181mutual exclusion lock 182on behalf of the currently running kernel thread. 183If another kernel thread is holding the mutex, 184the caller will spin until the mutex becomes available. 185Interrupts are disabled during the spin and remain disabled 186following the acquiring of the lock. 187.Pp 188It is possible for the same thread to recursively acquire a mutex 189with no ill effects, provided that the 190.Dv MTX_RECURSE 191bit was passed to 192.Fn mtx_init 193during the initialization of the mutex. 194.Pp 195The 196.Fn mtx_lock_flags 197and 198.Fn mtx_lock_spin_flags 199functions acquire a 200.Dv MTX_DEF 201or 202.Dv MTX_SPIN 203lock, respectively, and also accept a 204.Fa flags 205argument. 206In both cases, the only flag presently available for lock acquires is 207.Dv MTX_QUIET . 208If the 209.Dv MTX_QUIET 210bit is turned on in the 211.Fa flags 212argument, then if 213.Dv KTR_LOCK 214tracing is being done, 215it will be silenced during the lock acquire. 216.Pp 217The 218.Fn mtx_trylock 219function is used to acquire exclusive access 220to those objects protected by the mutex 221pointed to by 222.Fa mutex . 223If the mutex can not be immediately acquired 224.Fn mtx_try_enter 225will return 0, 226otherwise the mutex will be acquired 227and a non-zero value will be returned. 228.Pp 229The 230.Fn mtx_trylock_flags 231function has the same behavior as 232.Fn mtx_trylock 233but should be used when the caller desires to pass in a 234.Fa flags 235value. 236Presently, the only valid value in the 237.Fn mtx_trylock 238case is 239.Dv MTX_QUIET , 240and its effects are identical to those described for 241.Fn mtx_lock 242and 243.Fn mtx_lock_spin 244above. 245.Pp 246The 247.Fn mtx_unlock 248function releases a 249.Dv MTX_DEF 250mutual exclusion lock; 251if a higher priority thread is waiting for the mutex, 252the releasing thread will be disconnected 253to allow the higher priority thread to acquire the mutex and run. 254.Pp 255The 256.Fn mtx_unlock_spin 257function releases a 258.Dv MTX_SPIN 259mutual exclusion lock; 260interrupt state prior to the acquiring of the lock is restored. 261.Pp 262The 263.Fn mtx_unlock_flags 264and 265.Fn mtx_unlock_spin_flags 266functions behave in exactly the same way as do the standard mutex 267unlock routines above, while also allowing a 268.Fa flags 269argument which may only be 270.Dv MTX_QUIET 271in the 272.Fn mtx_unlock_spin_flags 273case, and may be one or more of 274.Dv MTX_QUIET 275and 276.Dv MTX_NOSWITCH 277in the 278.Fn mtx_unlock_flags 279case. 280The behavior of 281.Dv MTX_QUIET 282is identical to its behavior in the mutex lock routines. 283The 284.Dv MTX_NOSWITCH 285flag bit signifies, 286for a 287.Dv MTX_DEF 288mutex only, 289that the releasing thread is not to be disconnected from the CPU following 290the release of the mutex. 291.Pp 292The 293.Fn mtx_destroy 294function is used to destroy 295.Fa mutex 296so the data associated with it may be freed 297or otherwise overwritten. 298Any mutex which is destroyed 299must previously have been initialized with 300.Fn mtx_init . 301It is permissible to have a single hold count 302on a mutex when it is destroyed. 303It is not permissible to hold the mutex recursively, 304or have another process blocked on the mutex 305when it is destroyed. 306.Pp 307The 308.Fn mtx_owned 309function returns non-zero 310if the current process holds 311.Fa mutex . 312If the current process does not hold 313.Fa mutex 314zero is returned. 315.Pp 316The 317.Fn mtx_recursed 318function returns non-zero if the 319.Fa mutex 320is recursed. 321This check should only be made if the running thread already owns 322.Fa mutex . 323.Pp 324The 325.Fn mtx_assert 326function allows assertions to be made about 327.Fa mutex . 328If the assertions are not true and the kernel is compiled with 329.Dv INVARIANTS 330then the kernel will panic. 331Currently the following assertions are supported: 332.Bl -tag -width MA_NOTRECURSED 333.It Dv MA_OWNED 334Assert that the current thread 335holds the mutex 336pointed to by the first argument. 337.It Dv MA_NOTOWNED 338Assert that the current thread 339does not hold the mutex 340pointed to by the first argument. 341.It Dv MA_RECURSED 342Assert that the current thread has recursed on the mutex 343pointed to by the first argument. 344This assertion is only valid in conjuction with 345.Dv MA_OWNED . 346.It Dv MA_NOTRECURSED 347Assert that the current thread has not recursed on the mutex 348pointed to by the first argument. 349This assertion is only valid in conjuction with 350.Dv MA_OWNED . 351.El 352.Ss The Default Mutex Type 353Most kernel code should use the default lock type, 354.Dv MTX_DEF ; 355the default lock type will allow the thread 356to be disconnected from the CPU 357if it cannot get the lock. 358The machine dependent implementation 359may treat the lock as a short term spin lock 360under some circumstances. 361However, it is always safe to use these forms of locks 362in an interrupt thread 363without fear of deadlock 364against an interrupted thread on the same CPU. 365.Ss The Spin Mutex Type 366A 367.Dv MTX_SPIN 368mutex will not relinquish the CPU 369when it cannot immediately get the requested lock, 370but will loop, waiting for the mutex to be released by another CPU. 371This could result in deadlock 372if a thread interrupted the thread which held a mutex 373and then tried to acquire the mutex; 374for this reason spin locks will disable all interrupts 375(on the local CPU only). 376.Pp 377Spin locks are fairly specialized locks 378that are intended to be held for very short periods of time; 379their primary purpose is to protect portions of the code 380that implement default (i.e. sleep) locks. 381.Ss Initialization Options 382The options passed in the 383.Fa opts 384argument of 385.Fn mtx_init 386specify the mutex type. 387The possibilities are: 388.Bl -tag -width MTX_RECURSE 389.It Dv MTX_DEF 390Default lock type; 391will always allow the current thread to be suspended 392to avoid deadlock conditions against interrupt threads. 393The machine dependent implementation of this lock type 394may spin for a while before suspending the current thread. 395If this flag is specified, clearly 396.Dv MTX_SPIN 397must NOT be specified. 398.It Dv MTX_SPIN 399Spin lock type; 400will never relinquish the CPU. 401All interrupts are disabled on the local CPU 402while any spin lock is held. 403.It Dv MTX_RECURSE 404Recursion option bit; 405specifies that the initialized mutex is allowed to recurse. 406This bit must be present if the mutex is going to be permitted to recurse. 407It must always be accompanied by either 408.Dv MTX_DEF 409or 410.Dv MTX_SPIN 411but not both. 412.El 413.Ss Lock and Unlock Flags 414The flags passed to the 415.Fn mtx_lock_flags , 416.Fn mtx_lock_spin_flags , 417.Fn mtx_unlock_flags , 418and 419.Fn mtx_unlock_spin_flags 420functions provide some basic options to the caller, 421and are often used only under special circumstances to modify lock or 422unlock behavior. 423Standard locking and unlocking should be performed with the 424.Fn mtx_lock , 425.Fn mtx_lock_spin , 426.Fn mtx_unlock , 427and 428.Fn mtx_unlock_spin 429functions. 430If one of these flags is required then, and only then, 431should the corresponding flags-accepting routines be used. 432.Pp 433Options that modify mutex behavior: 434.Bl -tag -width MTX_NOSWITCH 435.It Dv MTX_NOSWITCH 436When releasing a 437.Dv MTX_DEF 438mutex, 439this flag prevents a thread switch that might occur 440if another higher priority thread was waiting for the mutex. 441This may cause priority inversion and should be used carefully. 442This flag can only be passed to 443.Fn mtx_unlock_flags . 444.Pp 445This flag is used internally by the lock code. 446It should not be used in general kernel code 447and is documented here for completeness only. 448.It Dv MTX_QUIET 449This option is used to quiet logging messages during mutex operations. 450This can be used to trim superfluous logging messages for debugging purposes. 451.El 452.Sh HISTORY 453These 454functions appeared in 455.Tn BSD/OS 4564.1 and 457.Fx 5.0 . 458