Lines Matching full:process

24 Priority inversion is when a lower priority process executes while a higher
25 priority process wants to run.  This happens for several reasons, and
26 most of the time it can't be helped.  Anytime a high priority process wants
27 to use a resource that a lower priority process has (a mutex for example),
28 the high priority process must wait until the lower priority process is done
31 priority process is prevented from running by a lower priority process for
36 priority process, C is the lowest, and B is in between. A tries to grab a lock
39 but by doing so, it is in fact preempting A which is a higher priority process.
64 PI is where a process inherits the priority of another process if the other
65 process blocks on a lock owned by the current process.  To make this easier
81            processes to inherit priorities from a previous process that is
102            process.  Since the scope of the waiter is within the code for
103            a process being blocked on the mutex, it is fine to allocate
104            the waiter on the process's stack (local variable).  This
117          - The highest priority process waiting on a specific mutex.
120               - The highest priority process waiting on one of the mutexes
121                 that a specific process owns.
124        task and process are used interchangeably in this document, mostly to
133 would never diverge, since a process can't be blocked on more than one
138    Process:  A, B, C, D, E
154 To show where two chains merge, we could add another process F and
161 Since a process may own more than one mutex, but never be blocked on more than
176 Also since a mutex may have more than one process blocked on it, we can
177 have multiple chains merge at mutexes.  If we add another process G that is
192 If process G has the highest priority in the chain, then all the tasks up
208 To keep track of the PI chains, each process has its own PI rbtree.  This is
209 a tree of all top waiters of the mutexes that are owned by the process.
211 blocked on mutexes owned by the process.
218 This tree is stored in the task structure of a process as a rbtree called
350 process must adjust its priority.  With the help of the pi_waiters of a
351 process this is rather easy to know what needs to be adjusted.
357 priority process that is waiting any of mutexes owned by the task. Since
372 process has just blocked on a mutex owned by the task, rt_mutex_adjust_prio
390 The rt_mutex_adjust_prio_chain can be used either to boost or lower process
394 (de)boosting (the owner of a mutex that a process is blocking on), a flag to
396 that is the process's waiter struct that is blocked on the mutex (although this
472 The accounting of a mutex and process is done with the waiter structure of
473 the process.  The "task" field is set to the process, and the "lock" field
478 add the waiter to the task waiter tree.  If the current process is the
479 highest priority process currently waiting on this mutex, then we remove the
480 previous top waiter process (if it exists) from the pi_waiters of the owner,
481 and add the current process to that tree.  Since the pi_waiter of the owner
489 Now all locks are released, and if the current process is still blocked on a
521 waiters, the owner field of the mutex would equal the current process and