Documentation/locking/pi-futex.rst

2 Lightweight PI-futexes
7  - in the user-space fastpath a PI-enabled futex involves no kernel work
9    calls - just pure fast atomic ops in userspace.
11  - even in the slowpath, the system call and scheduling pattern is very
14  - the in-kernel PI implementation is streamlined around the mutex
17    read-write lock support), only the owner may unlock a lock, no
20 Priority Inheritance - why?
21 ---------------------------
23 The short reply: user-space PI helps achieving/improving determinism for
24 user-space applications. In the best-case, it can help achieve
25 determinism and well-bound latencies. Even in the worst-case, PI will
30 ----------------
35 lockless structures are rather the exception than the norm - the current
46 short-held locks: for example, a highprio audio playback thread is
47 combined with medium-prio construct-audio-data threads and low-prio
48 display-colory-stuff threads. Add video and decoding to the mix and
52 unavoidable fact of life, and once we accept that multi-task userspace
53 apps have a very fair expectation of being able to use locks, we've got
55 implementation to user-space.
57 Most of the technical counter-arguments against doing priority
58 inheritance only apply to kernel-space locks. But user-space locks are
60 non-preemptible in a critical section, so the 'use spinlocks' argument
61 does not apply (user-space spinlocks have the same priority inversion
62 problems as other user-space locking constructs). Fact is, pretty much
64 locks (such as futex-based pthread mutexes) is priority inheritance:
66 Currently (without PI), if a high-prio and a low-prio task shares a lock
67 [this is a quite common scenario for most non-trivial RT applications],
71 deterministic execution of the high-prio task: any medium-priority task
72 could preempt the low-prio task while it holds the shared lock and
76 --------------
78 As mentioned before, the userspace fastpath of PI-enabled pthread
79 mutexes involves no kernel work at all - they behave quite similarly to
80 normal futex-based locks: a 0 value means unlocked, and a value==TID
81 means locked. (This is the same method as used by list-based robust
87   - FUTEX_LOCK_PI
88   - FUTEX_UNLOCK_PI
90 If the lock-acquire fastpath fails, [i.e. an atomic transition from 0 to
92 remaining work: if there is no futex-queue attached to the futex address
95 the futex-queue. The pi_state includes an rt-mutex, which is a PI-aware,
96 kernel-based synchronization object. The 'other' task is made the owner
97 of the rt-mutex, and the FUTEX_WAITERS bit is atomically set in the
98 futex value. Then this task tries to lock the rt-mutex, on which it
101 perform - it now owns the lock, and futex value contains
105 TID -> 0 atomic transition of the futex value], then no kernel work is
110 behalf of userspace - and it also unlocks the attached
111 pi_state->rt_mutex and thus wakes up any potential waiters.
113 Note that under this approach, contrary to previous PI-futex approaches,
114 there is no prior 'registration' of a PI-futex. [which is not quite
119 robust-futex, PI-futex, robust+PI-futex.
122 Documentation/locking/rt-mutex.rst.