Lines Matching refs:futex

11 A futex is in essence a user-space address, e.g. a 32-bit lock variable
16 creates a 'futex queue' internally, so that it can later on match up the
18 When the owner thread releases the futex, it notices (via the variable
21 taken and released the lock, the futex is again back to 'uncontended'
23 completely forgets that there ever was a futex at that address. This
38 There is a big conceptual problem with futex based mutexes though: it is
40 the kernel cannot help with the cleanup: if there is no 'futex queue'
47 is needed to release that futex based lock. This is one of the leading
72 are to be cleaned up, because a robust futex might have been registered
73 in another task, and the futex variable might have been simply mmap()-ed
89 time, the kernel checks this user-space list: are there any robust futex
105 list is done after the futex is acquired by glibc, there is a few
107 the futex hung. To protect against this possibility, userspace (glibc)
111 list_op_pending field before it tries to acquire the futex, and clears
114 That's all that is needed - all the rest of robust-futex cleanup is done
182 and even for robust futex users, there is only one extra syscall per
187 If a futex is found to be held at exit time, the kernel sets the
188 following bit of the futex word:
192 and wakes up the next futex waiter (if any). User-space does the rest of
196 the futex field atomically. Waiters set the FUTEX_WAITERS bit: