Lines Matching refs:futex
15 A futex is in essence a user-space address, e.g. a 32-bit lock variable
20 creates a 'futex queue' internally, so that it can later on match up the
22 When the owner thread releases the futex, it notices (via the variable
25 taken and released the lock, the futex is again back to 'uncontended'
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'
51 is needed to release that futex based lock. This is one of the leading
76 are to be cleaned up, because a robust futex might have been registered
77 in another task, and the futex variable might have been simply mmap()-ed
93 time, the kernel checks this user-space list: are there any robust futex
109 list is done after the futex is acquired by glibc, there is a few
111 the futex hung. To protect against this possibility, userspace (glibc)
115 list_op_pending field before it tries to acquire the futex, and clears
118 That's all that is needed - all the rest of robust-futex cleanup is done
186 and even for robust futex users, there is only one extra syscall per
191 If a futex is found to be held at exit time, the kernel sets the
192 following bit of the futex word::
196 and wakes up the next futex waiter (if any). User-space does the rest of
200 the futex field atomically. Waiters set the FUTEX_WAITERS bit::