Lines Matching refs:pending

548 pending ownership.  This means that it's the new owner, unless a higher
551 process "steal" the mutex from the pending owner (only if it is still pending)
566 If there is contention on the lock, whether it is owned or pending owner
596 mutex doesn't have a owner, or if we can steal the mutex from a pending
599   1) Has owner that is pending
604   current task.  This is because this function is also used for the pending
605   owner to grab the mutex.  When a pending owner wakes up, it checks to see
610   If the pending owner is not current, we check to see if the current priority is
611   higher than the pending owner.  If not, we fail the function and return.
613   There's also something special about a pending owner.  That is a pending owner
616   to update the pending owner's pi_list, since we only worry about processes
620   to take the top waiter, remove it from the pi_list of the pending owner, and
621   add it to the current pi_list.  Note that at this moment, the pending owner
622   is no longer on the list of waiters.  This is fine, since the pending owner
624   from itself.  When the pending owner tries to grab the mutex, it will fail
639   there exists an owner, or there's a pending owner with equal or higher
653 the pending owner.
660 or if the task is a pending owner and had its mutex stolen.  If the "task"
690   1) we were given pending ownership of the mutex.
743 pending ownership.
748 pending owner's waiter structure is set to NULL, and the owner field of the
753 The pi_lock of the previous owner is released, and the new pending owner's
758 We now clear the "pi_blocked_on" field of the new pending owner, and if
759 the mutex still has waiters pending, we add the new top waiter to the pi_list
760 of the pending owner.
762 Finally we unlock the pi_lock of the pending owner and wake it up.