[linux-2.6-block.git] / Documentation / locking / rt-mutex.rst

==================================
RT-mutex subsystem with PI support
==================================

RT-mutexes with priority inheritance are used to support PI-futexes,
which enable pthread_mutex_t priority inheritance attributes
(PTHREAD_PRIO_INHERIT). [See Documentation/pi-futex.txt for more details
about PI-futexes.]

This technology was developed in the -rt tree and streamlined for
pthread_mutex support.

Basic principles:
-----------------

RT-mutexes extend the semantics of simple mutexes by the priority
inheritance protocol.

A low priority owner of a rt-mutex inherits the priority of a higher
priority waiter until the rt-mutex is released. If the temporarily
boosted owner blocks on a rt-mutex itself it propagates the priority
boosting to the owner of the other rt_mutex it gets blocked on. The
priority boosting is immediately removed once the rt_mutex has been
unlocked.

This approach allows us to shorten the block of high-prio tasks on
mutexes which protect shared resources. Priority inheritance is not a
magic bullet for poorly designed applications, but it allows
well-designed applications to use userspace locks in critical parts of
an high priority thread, without losing determinism.

The enqueueing of the waiters into the rtmutex waiter tree is done in
priority order. For same priorities FIFO order is chosen. For each
rtmutex, only the top priority waiter is enqueued into the owner's
priority waiters tree. This tree too queues in priority order. Whenever
the top priority waiter of a task changes (for example it timed out or
got a signal), the priority of the owner task is readjusted. The
priority enqueueing is handled by "pi_waiters".

RT-mutexes are optimized for fastpath operations and have no internal
locking overhead when locking an uncontended mutex or unlocking a mutex
without waiters. The optimized fastpath operations require cmpxchg
support. [If that is not available then the rt-mutex internal spinlock
is used]

The state of the rt-mutex is tracked via the owner field of the rt-mutex
structure:

lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
keep track of the "lock has waiters" state:

 ============ ======= ================================================
 owner        bit0    Notes
 ============ ======= ================================================
 NULL         0       lock is free (fast acquire possible)
 NULL         1       lock is free and has waiters and the top waiter
		      is going to take the lock [1]_
 taskpointer  0       lock is held (fast release possible)
 taskpointer  1       lock is held and has waiters [2]_
 ============ ======= ================================================

The fast atomic compare exchange based acquire and release is only
possible when bit 0 of lock->owner is 0.

.. [1] It also can be a transitional state when grabbing the lock
       with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
       we need to set the bit0 before looking at the lock, and the owner may
       be NULL in this small time, hence this can be a transitional state.

.. [2] There is a small time when bit 0 is set but there are no
       waiters. This can happen when grabbing the lock in the slow path.
       To prevent a cmpxchg of the owner releasing the lock, we need to
       set this bit before looking at the lock.

BTW, there is still technically a "Pending Owner", it's just not called
that anymore. The pending owner happens to be the top_waiter of a lock
that has no owner and has been woken up to grab the lock.
Commit	Line	Data
387b1468	1	==================================
a6537be9	2	RT-mutex subsystem with PI support
387b1468	3	==================================
a6537be9 SR	4
	5	RT-mutexes with priority inheritance are used to support PI-futexes,
	6	which enable pthread_mutex_t priority inheritance attributes
	7	(PTHREAD_PRIO_INHERIT). [See Documentation/pi-futex.txt for more details
	8	about PI-futexes.]
	9
	10	This technology was developed in the -rt tree and streamlined for
	11	pthread_mutex support.
	12
	13	Basic principles:
	14	-----------------
	15
	16	RT-mutexes extend the semantics of simple mutexes by the priority
	17	inheritance protocol.
	18
	19	A low priority owner of a rt-mutex inherits the priority of a higher
	20	priority waiter until the rt-mutex is released. If the temporarily
	21	boosted owner blocks on a rt-mutex itself it propagates the priority
	22	boosting to the owner of the other rt_mutex it gets blocked on. The
	23	priority boosting is immediately removed once the rt_mutex has been
	24	unlocked.
	25
	26	This approach allows us to shorten the block of high-prio tasks on
	27	mutexes which protect shared resources. Priority inheritance is not a
	28	magic bullet for poorly designed applications, but it allows
	29	well-designed applications to use userspace locks in critical parts of
	30	an high priority thread, without losing determinism.
	31
68a1e349	32	The enqueueing of the waiters into the rtmutex waiter tree is done in
a6537be9 SR	33	priority order. For same priorities FIFO order is chosen. For each
a6537be9 SR	34	rtmutex, only the top priority waiter is enqueued into the owner's
68a1e349	35	priority waiters tree. This tree too queues in priority order. Whenever
a6537be9	36	the top priority waiter of a task changes (for example it timed out or
68a1e349 AS	37	got a signal), the priority of the owner task is readjusted. The
68a1e349 AS	38	priority enqueueing is handled by "pi_waiters".
a6537be9 SR	39
	40	RT-mutexes are optimized for fastpath operations and have no internal
	41	locking overhead when locking an uncontended mutex or unlocking a mutex
	42	without waiters. The optimized fastpath operations require cmpxchg
	43	support. [If that is not available then the rt-mutex internal spinlock
	44	is used]
	45
	46	The state of the rt-mutex is tracked via the owner field of the rt-mutex
	47	structure:
	48
68a1e349	49	lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
387b1468	50	keep track of the "lock has waiters" state:
a6537be9	51
387b1468 MCC	52	============ ======= ================================================
	53	owner bit0 Notes
	54	============ ======= ================================================
68a1e349 AS	55	NULL 0 lock is free (fast acquire possible)
68a1e349 AS	56	NULL 1 lock is free and has waiters and the top waiter
387b1468	57	is going to take the lock [1]_
68a1e349	58	taskpointer 0 lock is held (fast release possible)
387b1468 MCC	59	taskpointer 1 lock is held and has waiters [2]_
387b1468 MCC	60	============ ======= ================================================
a6537be9	61
68a1e349 AS	62	The fast atomic compare exchange based acquire and release is only
68a1e349 AS	63	possible when bit 0 of lock->owner is 0.
a6537be9	64
387b1468 MCC	65	.. [1] It also can be a transitional state when grabbing the lock
	66	with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
	67	we need to set the bit0 before looking at the lock, and the owner may
	68	be NULL in this small time, hence this can be a transitional state.
a6537be9	69
387b1468 MCC	70	.. [2] There is a small time when bit 0 is set but there are no
	71	waiters. This can happen when grabbing the lock in the slow path.
	72	To prevent a cmpxchg of the owner releasing the lock, we need to
	73	set this bit before looking at the lock.
68a1e349 AS	74
	75	BTW, there is still technically a "Pending Owner", it's just not called
	76	that anymore. The pending owner happens to be the top_waiter of a lock
	77	that has no owner and has been woken up to grab the lock.