xref: /freebsd/share/man/man9/mutex.9 (revision ee41f1b1cf5e3d4f586cb85b46123b416275862c)
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