Lines Matching refs:loop

432 A loop is entered, where task is the owner to be checked for PI changes that
438 If the task is not blocked on a mutex then the loop is exited.  We are at
446 or timeout and has left the PI chain.  In either case, the loop is exited, since
453 the loop.  Remember that the function started with the priority of the
460 lock, the pi_lock is released, and we restart the loop.
484 wait_lock, and continue the loop again.  On the next iteration of the
485 loop, the previous owner of the mutex will be the task that will be
492       we have taken that task's pi_lock at the beginning of the loop.
506       task and continue the loop, doing the end of PI chain check again.
513       but never give up the wait_lock.  So the PI chain loop is guaranteed to
647 Now we enter a loop that will continue to try to take ownership of the mutex, or
651 in the loop, since it had just failed to get the mutex.  But the second time
652 in the loop, this would likely succeed, since the task would likely be
659 on the mutex.  This field can be NULL the first time it goes through the loop
686 Waking up in the loop
694 In any of these cases, we continue the loop and once again try to grab the
695 ownership of the mutex.  If we succeed, we exit the loop, otherwise we continue
696 and on signal and timeout, will exit the loop, or if we had the mutex stolen