Lines Matching refs:there

14 that says "there's a waiter pending", and the sys_futex(FUTEX_WAIT)
19 value) that there were waiter(s) pending, and does the
22 state, and there's no in-kernel state associated with it. The kernel
23 completely forgets that there ever was a futex at that address. This
40 the kernel cannot help with the cleanup: if there is no 'futex queue'
41 (and in most cases there is none, futexes being fast lightweight locks)
71 because the kernel has no knowledge about how many robust futexes there
85 At the heart of this new approach there is a per-thread private list of
89 time, the kernel checks this user-space list: are there any robust futex
92 In the common case, at do_exit() time, there is no list registered, so
105 list is done after the futex is acquired by glibc, there is a few
106 instructions window for the thread (or process) to die there, leaving
123  - it's much, much faster: at thread exit time, there's no need to loop
141  - the implementation and the locking is "obvious", and there are no
181 So there is virtually zero overhead for tasks not using robust futexes,
182 and even for robust futex users, there is only one extra syscall per