1RT-mutex subsystem with PI support 2---------------------------------- 3 4RT-mutexes with priority inheritance are used to support PI-futexes, 5which enable pthread_mutex_t priority inheritance attributes 6(PTHREAD_PRIO_INHERIT). [See Documentation/pi-futex.txt for more details 7about PI-futexes.] 8 9This technology was developed in the -rt tree and streamlined for 10pthread_mutex support. 11 12Basic principles: 13----------------- 14 15RT-mutexes extend the semantics of simple mutexes by the priority 16inheritance protocol. 17 18A low priority owner of a rt-mutex inherits the priority of a higher 19priority waiter until the rt-mutex is released. If the temporarily 20boosted owner blocks on a rt-mutex itself it propagates the priority 21boosting to the owner of the other rt_mutex it gets blocked on. The 22priority boosting is immediately removed once the rt_mutex has been 23unlocked. 24 25This approach allows us to shorten the block of high-prio tasks on 26mutexes which protect shared resources. Priority inheritance is not a 27magic bullet for poorly designed applications, but it allows 28well-designed applications to use userspace locks in critical parts of 29an high priority thread, without losing determinism. 30 31The enqueueing of the waiters into the rtmutex waiter list is done in 32priority order. For same priorities FIFO order is chosen. For each 33rtmutex, only the top priority waiter is enqueued into the owner's 34priority waiters list. This list too queues in priority order. Whenever 35the top priority waiter of a task changes (for example it timed out or 36got a signal), the priority of the owner task is readjusted. [The 37priority enqueueing is handled by "plists", see include/linux/plist.h 38for more details.] 39 40RT-mutexes are optimized for fastpath operations and have no internal 41locking overhead when locking an uncontended mutex or unlocking a mutex 42without waiters. The optimized fastpath operations require cmpxchg 43support. [If that is not available then the rt-mutex internal spinlock 44is used] 45 46The state of the rt-mutex is tracked via the owner field of the rt-mutex 47structure: 48 49rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1 50are used to keep track of the "owner is pending" and "rtmutex has 51waiters" state. 52 53 owner bit1 bit0 54 NULL 0 0 mutex is free (fast acquire possible) 55 NULL 0 1 invalid state 56 NULL 1 0 Transitional state* 57 NULL 1 1 invalid state 58 taskpointer 0 0 mutex is held (fast release possible) 59 taskpointer 0 1 task is pending owner 60 taskpointer 1 0 mutex is held and has waiters 61 taskpointer 1 1 task is pending owner and mutex has waiters 62 63Pending-ownership handling is a performance optimization: 64pending-ownership is assigned to the first (highest priority) waiter of 65the mutex, when the mutex is released. The thread is woken up and once 66it starts executing it can acquire the mutex. Until the mutex is taken 67by it (bit 0 is cleared) a competing higher priority thread can "steal" 68the mutex which puts the woken up thread back on the waiters list. 69 70The pending-ownership optimization is especially important for the 71uninterrupted workflow of high-prio tasks which repeatedly 72takes/releases locks that have lower-prio waiters. Without this 73optimization the higher-prio thread would ping-pong to the lower-prio 74task [because at unlock time we always assign a new owner]. 75 76(*) The "mutex has waiters" bit gets set to take the lock. If the lock 77doesn't already have an owner, this bit is quickly cleared if there are 78no waiters. So this is a transitional state to synchronize with looking 79at the owner field of the mutex and the mutex owner releasing the lock. 80