Lines Matching refs:it
25 most of the time it can't be helped. Anytime a high priority process wants
37 meantime, B executes, and since B is of a higher priority than C, it preempts C,
38 but by doing so, it is in fact preempting A which is a higher priority process.
68 of A. So now if B becomes runnable, it would not preempt C, since C now has
69 the high priority of A. As soon as C releases the lock, it loses its
97 a process being blocked on the mutex, it is fine to allocate
163 also call it the Top of the chain) must be equal to or higher in priority
166 Also since a mutex may have more than one process blocked on it, we can
189 The implementation of plist is out of scope for this document, but it is
190 very important to understand what it does.
194 priorities of the plist are sorted, such that it takes O(1) to retrieve the
224 inherited a priority, it will always be the priority of the task that is
237 defined. But is very complex to figure it out, since it depends on all
298 functions individually, it seems as though they only have at most a locking
300 it still is very difficult to find the possibilities of that depth.
307 time, as it walks the PI chain. More about this below.
344 This is really nice to have, since it allows you to only update a variable
345 if the variable is what you expect it to be. You know if it succeeded if
354 the system for architectures that support it. This will also be explained
426 performed on it. This means that the task is set to the priority that it
443 waiter on the top of the task's pi_list. If it is not, it either means that
471 from the owner's pi_list, and replace it with the task.
478 If the task was not the top waiter of the mutex, but it was before we
509 the entire time, and it is not let go when we grab the pi_lock of the
518 unless you really want to make a proof out of it ;)
529 and be done with it?
534 blocked on, when the mutex is released it would be given to the lower priority
536 The high priority process would fail to take that mutex that it just gave up
537 and it would need to boost the lower priority process to run with full
539 it).
542 penalized if it tries to take that mutex again. If the new owner of the
547 new process is given a mutex that it was blocked on, it is only given
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
590 slow unlock path, and it would then need to grab the wait_lock, which this
602 The mutex has a owner, but it hasn't woken up and the mutex flag
605 owner to grab the mutex. When a pending owner wakes up, it checks to see
606 if it can take the mutex, and this is done if the owner is already set to
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
623 would add itself back when it realizes that it had the ownership stolen
624 from itself. When the pending owner tries to grab the mutex, it will fail
632 mutex actually has waiters, or we clear the flag if it doesn't. See, it was
633 OK that we set that flag early, since now it is cleared.
645 of this mutex if we failed to get it after a specified amount of time.
651 in the loop, since it had just failed to get the mutex. But the second time
659 on the mutex. This field can be NULL the first time it goes through the loop
661 field is NULL then we need to set up the accounting for it.
674 previous top waiter process (if it exists) from the pi_list of the owner,
712 but this time it will be lowering the priorities.
734 do have CMPXCHG, that check is done in the fast path, but it is still needed
762 Finally we unlock the pi_lock of the pending owner and wake it up.