2007-03-14 04:00:24 +00:00
|
|
|
.\" Copyright (c) 2007 Julian Elischer (julian - freebsd org )
|
|
|
|
|
.\" All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
|
.\"
|
|
|
|
|
.\" $FreeBSD$
|
|
|
|
|
.\"
|
2013-05-22 16:33:28 +00:00
|
|
|
.Dd May 22, 2013
|
2007-03-14 04:00:24 +00:00
|
|
|
.Dt LOCKING 9
|
|
|
|
|
.Os
|
|
|
|
|
.Sh NAME
|
2007-03-19 07:49:11 +00:00
|
|
|
.Nm locking
|
2007-03-14 04:00:24 +00:00
|
|
|
.Nd kernel synchronization primitives
|
|
|
|
|
.Sh DESCRIPTION
|
2007-06-01 03:11:47 +00:00
|
|
|
The
|
2007-03-14 04:00:24 +00:00
|
|
|
.Em FreeBSD
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
kernel is written to run across multiple CPUs and as such provides
|
|
|
|
|
several different synchronization primitives to allow developers
|
|
|
|
|
to safely access and manipulate many data types.
|
2007-08-09 21:09:56 +00:00
|
|
|
.Ss Mutexes
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Mutexes (also called "blocking mutexes") are the most commonly used
|
2010-02-13 12:03:03 +00:00
|
|
|
synchronization primitive in the kernel.
|
2012-06-27 01:13:37 +00:00
|
|
|
A thread acquires (locks) a mutex before accessing data shared with other
|
2010-01-28 17:09:47 +00:00
|
|
|
threads (including interrupt threads), and releases (unlocks) it afterwards.
|
2012-06-27 01:13:37 +00:00
|
|
|
If the mutex cannot be acquired, the thread requesting it will wait.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Mutexes are adaptive by default, meaning that
|
2012-06-27 01:13:37 +00:00
|
|
|
if the owner of a contended mutex is currently running on another CPU,
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
then a thread attempting to acquire the mutex will spin rather than yielding
|
|
|
|
|
the processor.
|
2010-01-28 19:57:24 +00:00
|
|
|
Mutexes fully support priority propagation.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr mutex 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Spin Mutexes
|
|
|
|
|
Spin mutexes are a variation of basic mutexes; the main difference between
|
|
|
|
|
the two is that spin mutexes never block.
|
|
|
|
|
Instead, they spin while waiting for the lock to be released.
|
|
|
|
|
Note that a thread that holds a spin mutex must never yield its CPU to
|
|
|
|
|
avoid deadlock.
|
|
|
|
|
Unlike ordinary mutexes, spin mutexes disable interrupts when acquired.
|
|
|
|
|
Since disabling interrupts can be expensive, they are generally slower to
|
|
|
|
|
acquire and release.
|
|
|
|
|
Spin mutexes should be used only when absolutely necessary,
|
|
|
|
|
e.g. to protect data shared
|
2010-02-13 12:03:03 +00:00
|
|
|
with interrupt filter code (see
|
|
|
|
|
.Xr bus_setup_intr 9
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
for details),
|
|
|
|
|
or for scheduler internals.
|
|
|
|
|
.Ss Mutex Pools
|
|
|
|
|
With most synchronization primitives, such as mutexes, the programmer must
|
|
|
|
|
provide memory to hold the primitive.
|
2010-01-28 17:09:47 +00:00
|
|
|
For example, a mutex may be embedded inside the structure it protects.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Mutex pools provide a preallocated set of mutexes to avoid this
|
|
|
|
|
requirement.
|
|
|
|
|
Note that mutexes from a pool may only be used as leaf locks.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr mtx_pool 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Reader/Writer Locks
|
|
|
|
|
Reader/writer locks allow shared access to protected data by multiple threads
|
2007-03-14 04:00:24 +00:00
|
|
|
or exclusive access by a single thread.
|
|
|
|
|
The threads with shared access are known as
|
|
|
|
|
.Em readers
|
2007-08-09 21:09:56 +00:00
|
|
|
since they should only read the protected data.
|
2007-03-14 04:00:24 +00:00
|
|
|
A thread with exclusive access is known as a
|
|
|
|
|
.Em writer
|
2007-08-09 21:09:56 +00:00
|
|
|
since it may modify protected data.
|
2007-03-14 04:00:24 +00:00
|
|
|
.Pp
|
2007-08-09 21:09:56 +00:00
|
|
|
Reader/writer locks can be treated as mutexes (see above and
|
2007-03-14 04:00:24 +00:00
|
|
|
.Xr mutex 9 )
|
|
|
|
|
with shared/exclusive semantics.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Reader/writer locks support priority propagation like mutexes,
|
|
|
|
|
but priority is propagated only to an exclusive holder.
|
2007-03-14 04:00:24 +00:00
|
|
|
This limitation comes from the fact that shared owners
|
|
|
|
|
are anonymous.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr rwlock 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Read-Mostly Locks
|
|
|
|
|
Read-mostly locks are similar to
|
2010-01-28 19:57:24 +00:00
|
|
|
.Em reader/writer
|
|
|
|
|
locks but optimized for very infrequent write locking.
|
|
|
|
|
.Em Read-mostly
|
2007-11-08 14:47:55 +00:00
|
|
|
locks implement full priority propagation by tracking shared owners
|
2010-02-15 17:41:59 +00:00
|
|
|
using a caller-supplied
|
2007-11-08 14:47:55 +00:00
|
|
|
.Em tracker
|
|
|
|
|
data structure.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr rmlock 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Sleepable Read-Mostly Locks
|
|
|
|
|
Sleepable read-mostly locks are a variation on read-mostly locks.
|
|
|
|
|
Threads holding an exclusive lock may sleep,
|
|
|
|
|
but threads holding a shared lock may not.
|
|
|
|
|
Priority is propagated to shared owners but not to exclusive owners.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Ss Shared/exclusive locks
|
2010-01-28 19:57:24 +00:00
|
|
|
Shared/exclusive locks are similar to reader/writer locks; the main difference
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
between them is that shared/exclusive locks may be held during unbounded sleep.
|
|
|
|
|
Acquiring a contested shared/exclusive lock can perform an unbounded sleep.
|
|
|
|
|
These locks do not support priority propagation.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr sx 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Lockmanager locks
|
|
|
|
|
Lockmanager locks are sleepable shared/exclusive locks used mostly in
|
|
|
|
|
.Xr VFS 9
|
|
|
|
|
.Po
|
|
|
|
|
as a
|
|
|
|
|
.Xr vnode 9
|
|
|
|
|
lock
|
|
|
|
|
.Pc
|
|
|
|
|
and in the buffer cache
|
|
|
|
|
.Po
|
|
|
|
|
.Xr BUF_LOCK 9
|
|
|
|
|
.Pc .
|
|
|
|
|
They have features other lock types do not have such as sleep
|
|
|
|
|
timeouts, blocking upgrades,
|
|
|
|
|
writer starvation avoidance, draining, and an interlock mutex,
|
|
|
|
|
but this makes them complicated to both use and implement;
|
|
|
|
|
for this reason, they should be avoided.
|
|
|
|
|
.Pp
|
|
|
|
|
See
|
|
|
|
|
.Xr lock 9
|
|
|
|
|
for details.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Ss Counting semaphores
|
|
|
|
|
Counting semaphores provide a mechanism for synchronizing access
|
|
|
|
|
to a pool of resources.
|
|
|
|
|
Unlike mutexes, semaphores do not have the concept of an owner,
|
|
|
|
|
so they can be useful in situations where one thread needs
|
|
|
|
|
to acquire a resource, and another thread needs to release it.
|
|
|
|
|
They are largely deprecated.
|
|
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr sema 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
2007-03-14 04:00:24 +00:00
|
|
|
.Ss Condition variables
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Condition variables are used in conjunction with locks to wait for
|
|
|
|
|
a condition to become true.
|
|
|
|
|
A thread must hold the associated lock before calling one of the
|
|
|
|
|
.Fn cv_wait ,
|
2007-03-14 04:00:24 +00:00
|
|
|
functions.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
When a thread waits on a condition, the lock
|
|
|
|
|
is atomically released before the thread yields the processor
|
|
|
|
|
and reacquired before the function call returns.
|
|
|
|
|
Condition variables may be used with blocking mutexes,
|
|
|
|
|
reader/writer locks, read-mostly locks, and shared/exclusive locks.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr condvar 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Sleep/Wakeup
|
2007-03-14 04:00:24 +00:00
|
|
|
The functions
|
|
|
|
|
.Fn tsleep ,
|
|
|
|
|
.Fn msleep ,
|
|
|
|
|
.Fn msleep_spin ,
|
|
|
|
|
.Fn pause ,
|
|
|
|
|
.Fn wakeup ,
|
|
|
|
|
and
|
|
|
|
|
.Fn wakeup_one
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
also handle event-based thread blocking.
|
|
|
|
|
Unlike condition variables,
|
|
|
|
|
arbitrary addresses may be used as wait channels and an dedicated
|
|
|
|
|
structure does not need to be allocated.
|
|
|
|
|
However, care must be taken to ensure that wait channel addresses are
|
|
|
|
|
unique to an event.
|
2007-03-18 19:28:44 +00:00
|
|
|
If a thread must wait for an external event, it is put to sleep by
|
2007-03-14 04:00:24 +00:00
|
|
|
.Fn tsleep ,
|
|
|
|
|
.Fn msleep ,
|
|
|
|
|
.Fn msleep_spin ,
|
|
|
|
|
or
|
|
|
|
|
.Fn pause .
|
|
|
|
|
Threads may also wait using one of the locking primitive sleep routines
|
|
|
|
|
.Xr mtx_sleep 9 ,
|
|
|
|
|
.Xr rw_sleep 9 ,
|
|
|
|
|
or
|
|
|
|
|
.Xr sx_sleep 9 .
|
|
|
|
|
.Pp
|
|
|
|
|
The parameter
|
|
|
|
|
.Fa chan
|
|
|
|
|
is an arbitrary address that uniquely identifies the event on which
|
|
|
|
|
the thread is being put to sleep.
|
|
|
|
|
All threads sleeping on a single
|
|
|
|
|
.Fa chan
|
|
|
|
|
are woken up later by
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Fn wakeup
|
|
|
|
|
.Pq often called from inside an interrupt routine
|
|
|
|
|
to indicate that the
|
|
|
|
|
event the thread was blocking on has occurred.
|
2007-03-14 04:00:24 +00:00
|
|
|
.Pp
|
|
|
|
|
Several of the sleep functions including
|
|
|
|
|
.Fn msleep ,
|
|
|
|
|
.Fn msleep_spin ,
|
|
|
|
|
and the locking primitive sleep routines specify an additional lock
|
|
|
|
|
parameter.
|
|
|
|
|
The lock will be released before sleeping and reacquired
|
|
|
|
|
before the sleep routine returns.
|
|
|
|
|
If
|
|
|
|
|
.Fa priority
|
|
|
|
|
includes the
|
|
|
|
|
.Dv PDROP
|
2007-03-18 19:28:44 +00:00
|
|
|
flag, then the lock will not be reacquired before returning.
|
2007-03-14 04:00:24 +00:00
|
|
|
The lock is used to ensure that a condition can be checked atomically,
|
|
|
|
|
and that the current thread can be suspended without missing a
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
change to the condition or an associated wakeup.
|
2007-03-14 04:00:24 +00:00
|
|
|
In addition, all of the sleep routines will fully drop the
|
|
|
|
|
.Va Giant
|
|
|
|
|
mutex
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Pq even if recursed
|
2007-03-14 04:00:24 +00:00
|
|
|
while the thread is suspended and will reacquire the
|
|
|
|
|
.Va Giant
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
mutex
|
|
|
|
|
.Pq restoring any recursion
|
|
|
|
|
before the function returns.
|
2007-03-14 04:00:24 +00:00
|
|
|
.Pp
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
The
|
|
|
|
|
.Fn pause
|
|
|
|
|
function is a special sleep function that waits for a specified
|
|
|
|
|
amount of time to pass before the thread resumes execution.
|
|
|
|
|
This sleep cannot be terminated early by either an explicit
|
|
|
|
|
.Fn wakeup
|
|
|
|
|
or a signal.
|
2010-01-28 17:09:47 +00:00
|
|
|
.Pp
|
2010-01-28 21:14:12 +00:00
|
|
|
See
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Xr sleep 9
|
2010-01-28 21:14:12 +00:00
|
|
|
for details.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Ss Giant
|
|
|
|
|
Giant is a special mutex used to protect data structures that do not
|
|
|
|
|
yet have their own locks.
|
|
|
|
|
Since it provides semantics akin to the old
|
|
|
|
|
.Xr spl 9
|
|
|
|
|
interface,
|
|
|
|
|
Giant has special characteristics:
|
|
|
|
|
.Bl -enum
|
|
|
|
|
.It
|
|
|
|
|
It is recursive.
|
|
|
|
|
.It
|
|
|
|
|
Drivers can request that Giant be locked around them
|
|
|
|
|
by not marking themselves MPSAFE.
|
|
|
|
|
Note that infrastructure to do this is slowly going away as non-MPSAFE
|
|
|
|
|
drivers either became properly locked or disappear.
|
|
|
|
|
.It
|
|
|
|
|
Giant must be locked before other non-sleepable locks.
|
|
|
|
|
.It
|
|
|
|
|
Giant is dropped during unbounded sleeps and reacquired after wakeup.
|
|
|
|
|
.It
|
|
|
|
|
There are places in the kernel that drop Giant and pick it back up
|
|
|
|
|
again.
|
|
|
|
|
Sleep locks will do this before sleeping.
|
|
|
|
|
Parts of the network or VM code may do this as well.
|
|
|
|
|
This means that you cannot count on Giant keeping other code from
|
|
|
|
|
running if your code sleeps, even if you want it to.
|
|
|
|
|
.El
|
2010-01-28 17:09:47 +00:00
|
|
|
.Sh INTERACTIONS
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
The primitives can interact and have a number of rules regarding how
|
2010-02-13 12:03:03 +00:00
|
|
|
they can and can not be combined.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Many of these rules are checked by
|
|
|
|
|
.Xr witness 4 .
|
|
|
|
|
.Ss Bounded vs. Unbounded Sleep
|
|
|
|
|
A bounded sleep
|
|
|
|
|
.Pq or blocking
|
|
|
|
|
is a sleep where the only resource needed to resume execution of a thread
|
|
|
|
|
is CPU time for the owner of a lock that the thread is waiting to acquire.
|
|
|
|
|
An unbounded sleep
|
|
|
|
|
.Po
|
|
|
|
|
often referred to as simply
|
|
|
|
|
.Dq sleeping
|
|
|
|
|
.Pc
|
|
|
|
|
is a sleep where a thread is waiting for an external event or for a condition
|
|
|
|
|
to become true.
|
|
|
|
|
In particular,
|
|
|
|
|
since there is always CPU time available,
|
|
|
|
|
a dependency chain of threads in bounded sleeps should always make forward
|
|
|
|
|
progress.
|
|
|
|
|
This requires that no thread in a bounded sleep is waiting for a lock held
|
|
|
|
|
by a thread in an unbounded sleep.
|
|
|
|
|
To avoid priority inversions,
|
|
|
|
|
a thread in a bounded sleep lends its priority to the owner of the lock
|
|
|
|
|
that it is waiting for.
|
2010-01-28 19:57:24 +00:00
|
|
|
.Pp
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
The following primitives perform bounded sleeps:
|
|
|
|
|
mutexes, reader/writer locks and read-mostly locks.
|
2010-01-28 19:57:24 +00:00
|
|
|
.Pp
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
The following primitives perform unbounded sleeps:
|
|
|
|
|
sleepable read-mostly locks, shared/exclusive locks, lockmanager locks,
|
|
|
|
|
counting semaphores, condition variables, and sleep/wakeup.
|
|
|
|
|
.Ss General Principles
|
|
|
|
|
.Bl -bullet
|
|
|
|
|
.It
|
2012-06-27 01:13:37 +00:00
|
|
|
It is an error to do any operation that could result in yielding the processor
|
|
|
|
|
while holding a spin mutex.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.It
|
|
|
|
|
It is an error to do any operation that could result in unbounded sleep
|
|
|
|
|
while holding any primitive from the 'bounded sleep' group.
|
|
|
|
|
For example, it is an error to try to acquire a shared/exclusive lock while
|
|
|
|
|
holding a mutex, or to try to allocate memory with M_WAITOK while holding a
|
|
|
|
|
reader/writer lock.
|
2010-01-28 19:57:24 +00:00
|
|
|
.Pp
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Note that the lock passed to one of the
|
2010-02-15 17:41:59 +00:00
|
|
|
.Fn sleep
|
2010-01-28 19:57:24 +00:00
|
|
|
or
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Fn cv_wait
|
|
|
|
|
functions is dropped before the thread enters the unbounded sleep and does
|
|
|
|
|
not violate this rule.
|
|
|
|
|
.It
|
2012-06-27 01:13:37 +00:00
|
|
|
It is an error to do any operation that could result in yielding of
|
|
|
|
|
the processor when running inside an interrupt filter.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.It
|
2010-02-10 17:02:06 +00:00
|
|
|
It is an error to do any operation that could result in unbounded sleep when
|
|
|
|
|
running inside an interrupt thread.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.El
|
2010-01-28 19:57:24 +00:00
|
|
|
.Ss Interaction table
|
2010-02-13 12:03:03 +00:00
|
|
|
The following table shows what you can and can not do while holding
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
one of the locking primitives discussed. Note that
|
|
|
|
|
.Dq sleep
|
|
|
|
|
includes
|
|
|
|
|
.Fn sema_wait ,
|
|
|
|
|
.Fn sema_timedwait ,
|
|
|
|
|
any of the
|
|
|
|
|
.Fn cv_wait
|
|
|
|
|
functions,
|
|
|
|
|
and any of the
|
|
|
|
|
.Fn sleep
|
|
|
|
|
functions.
|
|
|
|
|
.Bl -column ".Ic xxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXX" -offset 3n
|
|
|
|
|
.It Em " You want:" Ta spin mtx Ta mutex/rw Ta rmlock Ta sleep rm Ta sx/lk Ta sleep
|
|
|
|
|
.It Em "You have: " Ta -------- Ta -------- Ta ------ Ta -------- Ta ------ Ta ------
|
|
|
|
|
.It spin mtx Ta \&ok Ta \&no Ta \&no Ta \&no Ta \&no Ta \&no-1
|
|
|
|
|
.It mutex/rw Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no-1
|
|
|
|
|
.It rmlock Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no-1
|
|
|
|
|
.It sleep rm Ta \&ok Ta \&ok Ta \&ok Ta \&ok-2 Ta \&ok-2 Ta \&ok-2/3
|
|
|
|
|
.It sx Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok-3
|
|
|
|
|
.It lockmgr Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok
|
2007-03-14 04:00:24 +00:00
|
|
|
.El
|
|
|
|
|
.Pp
|
|
|
|
|
.Em *1
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
There are calls that atomically release this primitive when going to sleep
|
|
|
|
|
and reacquire it on wakeup
|
|
|
|
|
.Po
|
|
|
|
|
.Fn mtx_sleep ,
|
|
|
|
|
.Fn rw_sleep ,
|
|
|
|
|
.Fn msleep_spin ,
|
|
|
|
|
etc.
|
|
|
|
|
.Pc .
|
2007-03-14 04:00:24 +00:00
|
|
|
.Pp
|
|
|
|
|
.Em *2
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
These cases are only allowed while holding a write lock on a sleepable
|
|
|
|
|
read-mostly lock.
|
2007-03-14 04:00:24 +00:00
|
|
|
.Pp
|
|
|
|
|
.Em *3
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Though one can sleep while holding this lock,
|
|
|
|
|
one can also use a
|
|
|
|
|
.Fn sleep
|
|
|
|
|
function to atomically release this primitive when going to sleep and
|
2007-03-18 19:28:44 +00:00
|
|
|
reacquire it on wakeup.
|
2010-09-01 19:50:03 +00:00
|
|
|
.Pp
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
Note that non-blocking try operations on locks are always permitted.
|
2010-01-28 19:57:24 +00:00
|
|
|
.Ss Context mode table
|
2007-03-18 19:28:44 +00:00
|
|
|
The next table shows what can be used in different contexts.
|
|
|
|
|
At this time this is a rather easy to remember table.
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.Bl -column ".Ic Xxxxxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXX" -offset 3n
|
|
|
|
|
.It Em "Context:" Ta spin mtx Ta mutex/rw Ta rmlock Ta sleep rm Ta sx/lk Ta sleep
|
2012-03-29 05:02:12 +00:00
|
|
|
.It interrupt filter: Ta \&ok Ta \&no Ta \&no Ta \&no Ta \&no Ta \&no
|
Make a pass over this page to correct and clarify a few things as well as
some general word-smithing.
- Don't claim that adaptive mutexes have a timeout (they don't).
- Don't treat pool mutexes as a separate primitive in a few places.
- Describe sleepable read-mostly locks as a separate lock type and add
them to the various tables.
- Don't claim that sx locks are less efficient. That hasn't been true in
a few years now.
- Describe lockmanager locks next to sx locks since they are very similar
in terms of rules, etc., and so that all the lock primitives are
grouped together before the non-lock primitives.
- Similarly, move the section on Giant after the description of all the
non-lock primitives to preserve grouping.
- Condition variables work on several types of locks, not just mutexes.
- Add a bit of language to compare/contrast condition variables with
sleep/wakeup.
- Add a note about why pause(9) is unique.
- Add some language to define bounded vs unbounded sleeps and explain
why they are treated separately (bounded sleeps only need CPU time
to make forward progress).
- Don't state that using mtx_sleep() is a bad idea. It is in fact rather
necessary.
- Rework the interaction table a bit. First, it did not include really
include sleepable rmlocks and it left out lockmgr entirely. To get
things to fit, combine similar lock types into the same column / row,
and explicitly state what "sleep" means. The notes about recursion
and lock order were also a bit banal (lock order is always important,
not just in the few places annotated here), so remove them. In
particular, the lock order note would need to be on just about every
cell. If we want to document recursion I think a better approach
would be a separate table summarizing the recursion rules for each
lock as having too many notes clutters the table.
- Tweak the tables to use less indentation so everything still fits with
the added columns.
- Correct a few cells in the context mode table.
- Use mdoc markup instead of explicit markup in a few places.
Requested by: julian
MFC after: 2 weeks
2013-06-28 16:33:45 +00:00
|
|
|
.It interrupt thread: Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no
|
|
|
|
|
.It callout: Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no
|
|
|
|
|
.It system call: Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok
|
2007-03-14 06:27:02 +00:00
|
|
|
.El
|
2007-03-14 04:00:24 +00:00
|
|
|
.Sh SEE ALSO
|
2010-02-15 17:41:59 +00:00
|
|
|
.Xr witness 4 ,
|
2007-03-14 04:00:24 +00:00
|
|
|
.Xr condvar 9 ,
|
2007-06-21 16:39:25 +00:00
|
|
|
.Xr lock 9 ,
|
2007-03-14 04:00:24 +00:00
|
|
|
.Xr mtx_pool 9 ,
|
2007-08-09 21:09:56 +00:00
|
|
|
.Xr mutex 9 ,
|
2007-11-08 14:47:55 +00:00
|
|
|
.Xr rmlock 9 ,
|
2007-03-14 04:00:24 +00:00
|
|
|
.Xr rwlock 9 ,
|
|
|
|
|
.Xr sema 9 ,
|
|
|
|
|
.Xr sleep 9 ,
|
2007-06-21 16:39:25 +00:00
|
|
|
.Xr sx 9 ,
|
2010-11-03 18:49:50 +00:00
|
|
|
.Xr BUS_SETUP_INTR 9 ,
|
2010-01-28 17:09:47 +00:00
|
|
|
.Xr LOCK_PROFILING 9
|
2007-03-14 04:00:24 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
|
These
|
|
|
|
|
functions appeared in
|
2007-06-01 03:11:47 +00:00
|
|
|
.Bsx 4.1
|
2007-03-14 04:00:24 +00:00
|
|
|
through
|
2012-05-20 16:43:47 +00:00
|
|
|
.Fx 7.0 .
|
2010-01-28 17:09:47 +00:00
|
|
|
.Sh BUGS
|
|
|
|
|
There are too many locking primitives to choose from.
|
