Lines Matching refs:thread

9 The interesting data as to what futexes a thread is holding is kept on a
15  1) a one time call, per thread, to tell the kernel where its list of
18     by the exiting thread.
34 A thread that anticipates possibly using robust_futexes should first
42 bits on 64 bit arch's, and local byte order.  Each thread should have
43 its own thread private 'head'.
45 If a thread is running in 32 bit compatibility mode on a 64 native arch
62   word' holds 3 flag bits in the upper 3 bits, and the thread id (TID)
63   of the thread holding the lock in the bottom 29 bits.  See further
68   and is needed to correctly resolve races should a thread exit while
79 robust_futexes.  The kernel will only be able to wakeup the next thread
80 waiting for a lock on a threads exit if that next thread used the futex
83 For each futex lock currently held by a thread, if it wants this
86 specified 'offset'.  Should a thread die while holding any such locks,
88 indicating their holder died, and wakeup the next thread waiting for
91 When a thread has invoked the above system call to indicate it
104 robust_futexes used by that thread.  The thread should link those locks
110 pointer known to the kernel, the kernel can provide to a thread the
118 list 'head' is, and to walk the list on thread exit, handling locks
119 still held by the departing thread, as described below.
123 lock structures for locks currently held by that thread should be on
124 that thread's robust_futex linked lock list a given time.
128 thread currently holding such a lock, if any, is marked with the threads
141  3) add the lock entry, with its thread id (TID) in the bottom 29 bits
159     wakeup on that address, which will waken the next thread that has