Lines Matching refs:process

23 Priority inversion is when a lower priority process executes while a higher
24 priority process wants to run.  This happens for several reasons, and
25 most of the time it can't be helped.  Anytime a high priority process wants
26 to use a resource that a lower priority process has (a mutex for example),
27 the high priority process must wait until the lower priority process is done
30 priority process is prevented from running by a lower priority process for
35 priority process, C is the lowest, and B is in between. A tries to grab a lock
38 but by doing so, it is in fact preempting A which is a higher priority process.
63 PI is where a process inherits the priority of another process if the other
64 process blocks on a lock owned by the current process.  To make this easier
79            processes to inherit priorities from a previous process that is
96            process.  Since the scope of the waiter is within the code for
97            a process being blocked on the mutex, it is fine to allocate
98            the waiter on the process's stack (local variable).  This
109 top waiter - The highest priority process waiting on a specific mutex.
111 top pi waiter - The highest priority process waiting on one of the mutexes
112                 that a specific process owns.
114 Note:  task and process are used interchangeably in this document, mostly to
123 would never diverge, since a process can't be blocked on more than one
144 To show where two chains merge, we could add another process F and
151 Since a process may own more than one mutex, but never be blocked on more than
166 Also since a mutex may have more than one process blocked on it, we can
167 have multiple chains merge at mutexes.  If we add another process G that is
182 If process G has the highest priority in the chain, then all the tasks up
198 To keep track of the PI chains, each process has its own PI rbtree.  This is
199 a tree of all top waiters of the mutexes that are owned by the process.
201 blocked on mutexes owned by the process.
208 This tree is stored in the task structure of a process as a rbtree called
340 process must adjust its priority.  With the help of the pi_waiters of a
341 process this is rather easy to know what needs to be adjusted.
347 priority process that is waiting any of mutexes owned by the task. Since
361 process has just blocked on a mutex owned by the task, rt_mutex_adjust_prio
379 The rt_mutex_adjust_prio_chain can be used either to boost or lower process
383 (de)boosting (the owner of a mutex that a process is blocking on), a flag to
385 that is the process's waiter struct that is blocked on the mutex (although this
460 The accounting of a mutex and process is done with the waiter structure of
461 the process.  The "task" field is set to the process, and the "lock" field
466 add the waiter to the task waiter tree.  If the current process is the
467 highest priority process currently waiting on this mutex, then we remove the
468 previous top waiter process (if it exists) from the pi_waiters of the owner,
469 and add the current process to that tree.  Since the pi_waiter of the owner
477 Now all locks are released, and if the current process is still blocked on a
509 waiters, the owner field of the mutex would equal the current process and