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 tree 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 tree. This tree 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 "pi_waiters".
38
39RT-mutexes are optimized for fastpath operations and have no internal
40locking overhead when locking an uncontended mutex or unlocking a mutex
41without waiters. The optimized fastpath operations require cmpxchg
42support. [If that is not available then the rt-mutex internal spinlock
43is used]
44
45The state of the rt-mutex is tracked via the owner field of the rt-mutex
46structure:
47
48lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
49keep 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
58The fast atomic compare exchange based acquire and release is only
59possible when bit 0 of lock->owner is 0.
60
61(*) It also can be a transitional state when grabbing the lock
62with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
63we need to set the bit0 before looking at the lock, and the owner may be
64NULL 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
67waiters. This can happen when grabbing the lock in the slow path.
68To prevent a cmpxchg of the owner releasing the lock, we need to
69set this bit before looking at the lock.
70
71BTW, there is still technically a "Pending Owner", it's just not called
72that anymore. The pending owner happens to be the top_waiter of a lock
73that has no owner and has been woken up to grab the lock.
74