Lines Matching refs:futex

7  - in the user-space fastpath a PI-enabled futex involves no kernel work
64 locks (such as futex-based pthread mutexes) is priority inheritance:
80 normal futex-based locks: a 0 value means unlocked, and a value==TID
85 To handle the slowpath, we have added two new futex ops:
92 remaining work: if there is no futex-queue attached to the futex address
93 yet then the code looks up the task that owns the futex [it has put its
94 own TID into the futex value], and attaches a 'PI state' structure to
95 the futex-queue. The pi_state includes an rt-mutex, which is a PI-aware,
98 futex value. Then this task tries to lock the rt-mutex, on which it
100 futex value to its own TID and returns. Userspace has no other work to
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
109 then FUTEX_UNLOCK_PI is called, and the kernel unlocks the futex on the
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
118 properties of futexes, and all four combinations are possible: futex,
119 robust-futex, PI-futex, robust+PI-futex.