Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
LOCKING(9)	       FreeBSD Kernel Developer's Manual	    LOCKING(9)

NAME
     locking --	kernel synchronization primitives

DESCRIPTION
     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 syn-
     chronization 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 run-
     ning 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.

   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.	 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.

   Mutex Pools
     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 preal-
     located 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/Writer Locks
     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-Mostly Locks
     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.

   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 exclu-
     sive owners.

   Shared/exclusive locks
     Shared/exclusive locks are	similar	to reader/writer locks;	the main dif-
     ference 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.

   Lockmanager locks
     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,	block-
     ing 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.

   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.

     See sema(9) for details.

   Condition variables
     Condition variables are used in conjunction with locks to wait for	a con-
     dition to become true.  A thread must hold	the associated lock before
     calling one of the	cv_wait(), functions.  When a thread waits on a	condi-
     tion, the lock is atomically released before the thread yields the	pro-
     cessor and	reacquired before the function call returns.  Condition	vari-
     ables 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 dedi-
     cated 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 speci-
     fied amount of time to pass before	the thread resumes execution.  This
     sleep cannot be terminated	early by either	an explicit wakeup() or	a sig-
     nal.

     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 net-
	  work 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.

INTERACTIONS
     The primitives can	interact and have a number of rules regarding how they
     can and can not be	combined.  Many	of these rules are checked by
     witness(4).

   Bounded vs. Unbounded Sleep
     In	a bounded sleep	(also referred to as ``blocking'') 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.  In an	unbounded sleep	(often
     referred to as simply ``sleeping'') a thread waits	for an external	event
     or	for a condition	to become true.	 In particular,	a dependency chain of
     threads in	bounded	sleeps should always make forward progress, since
     there is always CPU time available.  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.

     The following primitives perform bounded sleeps: mutexes, reader/writer
     locks and read-mostly locks.

     The following primitives perform unbounded	sleeps:	sleepable read-mostly
     locks, shared/exclusive locks, lockmanager	locks, counting	semaphores,
     condition variables, and sleep/wakeup.

   General Principles
     +o	 It is an error	to do any operation that could result in yielding the
	 processor while holding a spin	mutex.

     +o	 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.

	 Note that the lock passed to one of the sleep() or cv_wait() func-
	 tions is dropped before the thread enters the unbounded sleep and
	 does not violate this rule.

     +o	 It is an error	to do any operation that could result in yielding of
	 the processor when running inside an interrupt	filter.

     +o	 It is an error	to do any operation that could result in unbounded
	 sleep when running inside an interrupt	thread.

   Interaction table
     The following table shows what you	can and	can not	do while holding one
     of	the locking primitives discussed.  Note	that ``sleep'' includes
     sema_wait(), sema_timedwait(), any	of the cv_wait() functions, and	any of
     the sleep() functions.

	       You want: spin mtx  mutex/rw  rmlock  sleep rm  sx/lk  sleep
	You have:	 --------  --------  ------  --------  ------ ------
	spin mtx	 ok	   no	     no	     no	       no     no-1
	mutex/rw	 ok	   ok	     ok	     no	       no     no-1
	rmlock		 ok	   ok	     ok	     no	       no     no-1
	sleep rm	 ok	   ok	     ok	     ok-2      ok-2   ok-2/3
	sx		 ok	   ok	     ok	     ok	       ok     ok-3
	lockmgr		 ok	   ok	     ok	     ok	       ok     ok

     *1	There are calls	that atomically	release	this primitive when going to
     sleep and reacquire it on wakeup (mtx_sleep(), rw_sleep(),	msleep_spin(),
     etc.).

     *2	These cases are	only allowed while holding a write lock	on a sleepable
     read-mostly lock.

     *3	Though one can sleep while holding this	lock, one can also use a
     sleep() function to atomically release this primitive when	going to sleep
     and reacquire it on wakeup.

     Note that non-blocking try	operations on locks are	always permitted.

   Context mode	table
     The next table shows what can be used in different	contexts.  At this
     time this is a rather easy	to remember table.

	Context:	    spin mtx  mutex/rw	rmlock	sleep rm  sx/lk	 sleep
	interrupt filter:   ok	      no	no	no	  no	 no
	interrupt thread:   ok	      ok	ok	no	  no	 no
	callout:	    ok	      ok	ok	no	  no	 no
	system call:	    ok	      ok	ok	ok	  ok	 ok

SEE ALSO
     witness(4), condvar(9), lock(9), mtx_pool(9), mutex(9), rmlock(9),
     rwlock(9),	sema(9), sleep(9), sx(9), BUS_SETUP_INTR(9), LOCK_PROFILING(9)

HISTORY
     These functions appeared in BSD/OS	4.1 through FreeBSD 7.0.

BUGS
     There are too many	locking	primitives to choose from.

FreeBSD	10.1			 June 30, 2013			  FreeBSD 10.1

NAME | DESCRIPTION | INTERACTIONS | SEE ALSO | HISTORY | BUGS

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=locking&sektion=9&manpath=FreeBSD+10.1-RELEASE>

home | help