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