Lines Matching refs:it

13 someone else wants to grab it too) then the lock is marked with a value
15 syscall is used to wait for the other guy to release it. The kernel
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
22 state, and there's no in-kernel state associated with it. The kernel
38 There is a big conceptual problem with futex based mutexes though: it is
44 the one that crashes, so it has no opportunity to clean up. Catch-22.
58  - it has quite complex locking and race scenarios. The vma-based
77 normal kernels can turn it off, but worse than that: the overhead makes
97 walks the list [not trusting it], and marks all locks that are owned by
102 so it can be accessed by the kernel in a lockless way.
110 before it could have added itself to the list. Glibc sets this
111 list_op_pending field before it tries to acquire the futex, and clears
112 it after the list-add (or list-remove) has finished.
123  - it's much, much faster: at thread exit time, there's no need to loop
154 [which it currently does for !pshared robust mutexes], and that took 256
159 locks to be held at a time. Nevertheless it's nice to know that this
183 thread lifetime, and the cleanup operation, if it happens, is fast and
210 tested the new glibc code (on x86_64 and i386), and it works for his