78 lines · plain
1==================================2RT-mutex subsystem with PI support3==================================4 5RT-mutexes with priority inheritance are used to support PI-futexes,6which enable pthread_mutex_t priority inheritance attributes7(PTHREAD_PRIO_INHERIT). [See Documentation/locking/pi-futex.rst for more details8about PI-futexes.]9 10This technology was developed in the -rt tree and streamlined for11pthread_mutex support.12 13Basic principles:14-----------------15 16RT-mutexes extend the semantics of simple mutexes by the priority17inheritance protocol.18 19A low priority owner of a rt-mutex inherits the priority of a higher20priority waiter until the rt-mutex is released. If the temporarily21boosted owner blocks on a rt-mutex itself it propagates the priority22boosting to the owner of the other rt_mutex it gets blocked on. The23priority boosting is immediately removed once the rt_mutex has been24unlocked.25 26This approach allows us to shorten the block of high-prio tasks on27mutexes which protect shared resources. Priority inheritance is not a28magic bullet for poorly designed applications, but it allows29well-designed applications to use userspace locks in critical parts of30an high priority thread, without losing determinism.31 32The enqueueing of the waiters into the rtmutex waiter tree is done in33priority order. For same priorities FIFO order is chosen. For each34rtmutex, only the top priority waiter is enqueued into the owner's35priority waiters tree. This tree too queues in priority order. Whenever36the top priority waiter of a task changes (for example it timed out or37got a signal), the priority of the owner task is readjusted. The38priority enqueueing is handled by "pi_waiters".39 40RT-mutexes are optimized for fastpath operations and have no internal41locking overhead when locking an uncontended mutex or unlocking a mutex42without waiters. The optimized fastpath operations require cmpxchg43support. [If that is not available then the rt-mutex internal spinlock44is used]45 46The state of the rt-mutex is tracked via the owner field of the rt-mutex47structure:48 49lock->owner holds the task_struct pointer of the owner. Bit 0 is used to50keep track of the "lock has waiters" state:51 52 ============ ======= ================================================53 owner bit0 Notes54 ============ ======= ================================================55 NULL 0 lock is free (fast acquire possible)56 NULL 1 lock is free and has waiters and the top waiter57 is going to take the lock [1]_58 taskpointer 0 lock is held (fast release possible)59 taskpointer 1 lock is held and has waiters [2]_60 ============ ======= ================================================61 62The fast atomic compare exchange based acquire and release is only63possible when bit 0 of lock->owner is 0.64 65.. [1] It also can be a transitional state when grabbing the lock66 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 may68 be NULL in this small time, hence this can be a transitional state.69 70.. [2] There is a small time when bit 0 is set but there are no71 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 to73 set this bit before looking at the lock.74 75BTW, there is still technically a "Pending Owner", it's just not called76that anymore. The pending owner happens to be the top_waiter of a lock77that has no owner and has been woken up to grab the lock.78