Lines Matching refs:waiter
95 waiter - A waiter is a struct that is stored on the stack of a blocked
96 process. Since the scope of the waiter is within the code for
98 the waiter on the process's stack (local variable). This
104 waiter is sometimes used in reference to the task that is waiting
105 on a mutex. This is the same as waiter->task.
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
210 wait_lock. Since the modification of the waiter list is never done in
376 to compare the top pi waiter to its own normal priority, and return the higher
397 by the task, so we only need to compare the priority of that top pi waiter
415 check for deadlocking, the mutex that the task owns, and a pointer to a waiter
416 that is the process's waiter struct that is blocked on the mutex (although this
427 should be at, but the plist nodes of the task's waiter have not been updated
441 A check is now done to see if the original waiter (the process that is blocked
442 on the current mutex) is the top pi waiter of the task. That is, is this
443 waiter on the top of the task's pi_list. If it is not, it either means that
445 mutexes that the task owns, or that the waiter has just woken up via a signal
449 walk is only needed when a new top pi waiter is made to a task.
451 The next check sees if the task's waiter plist node has the priority equal to
463 the mutex the task is blocked on, we update the task's waiter's plist node
470 process on the mutex's wait_list, then we remove the previous top waiter
473 Note: It is possible that the task was the current top waiter on the mutex,
474 in which case the task is not yet on the pi_list of the waiter. This
478 If the task was not the top waiter of the mutex, but it was before we
481 and the new top waiter is added.
498 task's waiter structure "task" element is NULL. This check is
500 sets the task's waiter structure "task" element to NULL with only
569 The slow path function is where the task's waiter structure is created on
570 the stack. This is because the waiter structure is only needed for the
571 scope of this function. The waiter structure holds the nodes to store
587 yet, so we assume we are going to be a waiter. The reason for this is to
620 to take the top waiter, remove it from the pi_list of the pending owner, and
658 The waiter structure has a "task" field that points to the task that is blocked
666 The accounting of a mutex and process is done with the waiter structure of
672 add the waiter to the wait_list. If the current process is the highest
674 previous top waiter process (if it exists) from the pi_list of the owner,
684 mutex (waiter "task" field is not NULL), then we go to sleep (call schedule).
708 If a timeout or signal occurred, the waiter's "task" field would not be
733 determine if a waiter needs to be awoken or not. On architectures that
735 in the slow path too. If a waiter of a mutex woke up because of a signal
742 If there are waiters, then we need to wake one up and give that waiter
746 waiter of the lock is found and removed from the wait_list of the mutex
748 pending owner's waiter structure is set to NULL, and the owner field of the
755 condition in rt_mutex_adjust_prio_chain from adding itself as a waiter
759 the mutex still has waiters pending, we add the new top waiter to the pi_list