| 1 | ==================================
|
| 2 | RT-mutex subsystem with PI support
|
| 3 | ==================================
|
| 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/locking/pi-futex.rst 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 |
|
| 32 | The enqueueing of the waiters into the rtmutex waiter tree is done in
|
| 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
|
| 35 | priority waiters tree. This tree too queues in priority order. Whenever
|
| 36 | the top priority waiter of a task changes (for example it timed out or
|
| 37 | got a signal), the priority of the owner task is readjusted. The
|
| 38 | priority enqueueing is handled by "pi_waiters".
|
| 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 |
|
| 49 | lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
|
| 50 | keep track of the "lock has waiters" state:
|
| 51 |
|
| 52 | ============ ======= ================================================
|
| 53 | owner bit0 Notes
|
| 54 | ============ ======= ================================================
|
| 55 | NULL 0 lock is free (fast acquire possible)
|
| 56 | NULL 1 lock is free and has waiters and the top waiter
|
| 57 | is going to take the lock
|
| 58 | taskpointer 0 lock is held (fast release possible)
|
| 59 | taskpointer 1 lock is held and has waiters
|
| 60 | ============ ======= ================================================
|
| 61 |
|
| 62 | The fast atomic compare exchange based acquire and release is only
|
| 63 | possible when bit 0 of lock->owner is 0.
|
| 64 |
|
| 65 |
|
| 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.
|
| 69 |
|
| 70 |
|
| 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.
|
| 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.
|