0001 ==================================
0002 RT-mutex subsystem with PI support
0003 ==================================
0004
0005 RT-mutexes with priority inheritance are used to support PI-futexes,
0006 which enable pthread_mutex_t priority inheritance attributes
0007 (PTHREAD_PRIO_INHERIT). [See Documentation/locking/pi-futex.rst for more details
0008 about PI-futexes.]
0009
0010 This technology was developed in the -rt tree and streamlined for
0011 pthread_mutex support.
0012
0013 Basic principles:
0014 -----------------
0015
0016 RT-mutexes extend the semantics of simple mutexes by the priority
0017 inheritance protocol.
0018
0019 A low priority owner of a rt-mutex inherits the priority of a higher
0020 priority waiter until the rt-mutex is released. If the temporarily
0021 boosted owner blocks on a rt-mutex itself it propagates the priority
0022 boosting to the owner of the other rt_mutex it gets blocked on. The
0023 priority boosting is immediately removed once the rt_mutex has been
0024 unlocked.
0025
0026 This approach allows us to shorten the block of high-prio tasks on
0027 mutexes which protect shared resources. Priority inheritance is not a
0028 magic bullet for poorly designed applications, but it allows
0029 well-designed applications to use userspace locks in critical parts of
0030 an high priority thread, without losing determinism.
0031
0032 The enqueueing of the waiters into the rtmutex waiter tree is done in
0033 priority order. For same priorities FIFO order is chosen. For each
0034 rtmutex, only the top priority waiter is enqueued into the owner's
0035 priority waiters tree. This tree too queues in priority order. Whenever
0036 the top priority waiter of a task changes (for example it timed out or
0037 got a signal), the priority of the owner task is readjusted. The
0038 priority enqueueing is handled by "pi_waiters".
0039
0040 RT-mutexes are optimized for fastpath operations and have no internal
0041 locking overhead when locking an uncontended mutex or unlocking a mutex
0042 without waiters. The optimized fastpath operations require cmpxchg
0043 support. [If that is not available then the rt-mutex internal spinlock
0044 is used]
0045
0046 The state of the rt-mutex is tracked via the owner field of the rt-mutex
0047 structure:
0048
0049 lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
0050 keep track of the "lock has waiters" state:
0051
0052 ============ ======= ================================================
0053 owner bit0 Notes
0054 ============ ======= ================================================
0055 NULL 0 lock is free (fast acquire possible)
0056 NULL 1 lock is free and has waiters and the top waiter
0057 is going to take the lock [1]_
0058 taskpointer 0 lock is held (fast release possible)
0059 taskpointer 1 lock is held and has waiters [2]_
0060 ============ ======= ================================================
0061
0062 The fast atomic compare exchange based acquire and release is only
0063 possible when bit 0 of lock->owner is 0.
0064
0065 .. [1] It also can be a transitional state when grabbing the lock
0066 with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
0067 we need to set the bit0 before looking at the lock, and the owner may
0068 be NULL in this small time, hence this can be a transitional state.
0069
0070 .. [2] There is a small time when bit 0 is set but there are no
0071 waiters. This can happen when grabbing the lock in the slow path.
0072 To prevent a cmpxchg of the owner releasing the lock, we need to
0073 set this bit before looking at the lock.
0074
0075 BTW, there is still technically a "Pending Owner", it's just not called
0076 that anymore. The pending owner happens to be the top_waiter of a lock
0077 that has no owner and has been woken up to grab the lock.
