Lines Matching refs:futex

6  - in the user-space fastpath a PI-enabled futex involves no kernel work
63 locks (such as futex-based pthread mutexes) is priority inheritance:
79 normal futex-based locks: a 0 value means unlocked, and a value==TID
84 To handle the slowpath, we have added two new futex ops:
91 remaining work: if there is no futex-queue attached to the futex address
92 yet then the code looks up the task that owns the futex [it has put its
93 own TID into the futex value], and attaches a 'PI state' structure to
94 the futex-queue. The pi_state includes an rt-mutex, which is a PI-aware,
97 futex value. Then this task tries to lock the rt-mutex, on which it
99 futex value to its own TID and returns. Userspace has no other work to
100 perform - it now owns the lock, and futex value contains
104 TID -> 0 atomic transition of the futex value], then no kernel work is
108 then FUTEX_UNLOCK_PI is called, and the kernel unlocks the futex on the
112 Note that under this approach, contrary to previous PI-futex approaches,
113 there is no prior 'registration' of a PI-futex. [which is not quite
117 properties of futexes, and all four combinations are possible: futex,
118 robust-futex, PI-futex, robust+PI-futex.