Lines Matching full:there

18 that says "there's a waiter pending", and the sys_futex(FUTEX_WAIT)
23 value) that there were waiter(s) pending, and does the
26 state, and there's no in-kernel state associated with it. The kernel
27 completely forgets that there ever was a futex at that address. This
42 There is a big conceptual problem with futex based mutexes though: it is
44 the kernel cannot help with the cleanup: if there is no 'futex queue'
45 (and in most cases there is none, futexes being fast lightweight locks)
75 because the kernel has no knowledge about how many robust futexes there
89 At the heart of this new approach there is a per-thread private list of
93 time, the kernel checks this user-space list: are there any robust futex
96 In the common case, at do_exit() time, there is no list registered, so
108 There is one race possible though: since adding to and removing from the
109 list is done after the futex is acquired by glibc, there is a few
110 instructions window for the thread (or process) to die there, leaving
127  - it's much, much faster: at thread exit time, there's no need to loop
145  - the implementation and the locking is "obvious", and there are no
185 So there is virtually zero overhead for tasks not using robust futexes,
186 and even for robust futex users, there is only one extra syscall per