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