The FreeBSD 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.
Mutexes
Mutexes (also called "blocking mutexes") are the most commonly used synchronization primitive in the
kernel. A thread acquires (locks) a mutex before accessing data shared with other threads (including
interrupt threads), and releases (unlocks) it afterwards. If the mutex cannot be acquired, the thread
requesting it will wait. Mutexes are adaptive by default, meaning that if the owner of a contended mutex
is currently running on another CPU, then a thread attempting to acquire the mutex will spin rather than
yielding the processor. Mutexes fully support priority propagation.
See mutex(9) for details.
SpinMutexes
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. To avoid deadlock, a thread
that holds a spin mutex must never yield its CPU. 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 with interrupt filter code (see bus_setup_intr(9) for details), or for scheduler internals.
MutexPools
With most synchronization primitives, such as mutexes, the programmer must provide memory to hold the
primitive. For example, a mutex may be embedded inside the structure it protects. 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.
See mtx_pool(9) for details.
Reader/WriterLocks
Reader/writer locks allow shared access to protected data by multiple threads or exclusive access by a
single thread. The threads with shared access are known as readers since they should only read the
protected data. A thread with exclusive access is known as a writer since it may modify protected data.
Reader/writer locks can be treated as mutexes (see above and mutex(9)) with shared/exclusive semantics.
Reader/writer locks support priority propagation like mutexes, but priority is propagated only to an
exclusive holder. This limitation comes from the fact that shared owners are anonymous.
See rwlock(9) for details.
Read-MostlyLocks
Read-mostly locks are similar to reader/writer locks but optimized for very infrequent write locking.
Read-mostly locks implement full priority propagation by tracking shared owners using a caller-supplied
tracker data structure.
See rmlock(9) for details.
SleepableRead-MostlyLocks
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.
Shared/exclusivelocks
Shared/exclusive locks are similar to reader/writer locks; the main difference 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.
See sx(9) for details.
Lockmanagerlocks
Lockmanager locks are sleepable shared/exclusive locks used mostly in VFS(9) (as a vnode(9) lock) and in
the buffer cache (BUF_LOCK(9)). 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 both to use and to implement; for this reason, they should be avoided.
See lock(9) for details.
Countingsemaphores
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.
See sema(9) for details.
Conditionvariables
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 cv_wait(), functions. 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.
See condvar(9) for details.
Sleep/Wakeup
The functions tsleep(), msleep(), msleep_spin(), pause(), wakeup(), and wakeup_one() also handle event-
based thread blocking. Unlike condition variables, arbitrary addresses may be used as wait channels and
a dedicated structure does not need to be allocated. However, care must be taken to ensure that wait
channel addresses are unique to an event. If a thread must wait for an external event, it is put to
sleep by tsleep(), msleep(), msleep_spin(), or pause(). Threads may also wait using one of the locking
primitive sleep routines mtx_sleep(9), rw_sleep(9), or sx_sleep(9).
The parameter 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 chan are woken up later by wakeup() (often called
from inside an interrupt routine) to indicate that the event the thread was blocking on has occurred.
Several of the sleep functions including msleep(), 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 priority includes the PDROP flag, then the lock will not be
reacquired before returning. The lock is used to ensure that a condition can be checked atomically, and
that the current thread can be suspended without missing a change to the condition or an associated
wakeup. In addition, all of the sleep routines will fully drop the Giant mutex (even if recursed) while
the thread is suspended and will reacquire the Giant mutex (restoring any recursion) before the function
returns.
The 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 wakeup() or a
signal.
See sleep(9) for details.
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 spl(9) interface, Giant has special characteristics:
1. It is recursive.
2. 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.
3. Giant must be locked before other non-sleepable locks.
4. Giant is dropped during unbounded sleeps and reacquired after wakeup.
5. 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.
Install Now
PNG Icons
Emojis
SVG Icons