Lines Matching refs:since

37 meantime, B executes, and since B is of a higher priority than C, it preempts C,
68 of A.  So now if B becomes runnable, it would not preempt C, since C now has
123 would never diverge, since a process can't be blocked on more than one
166 Also since a mutex may have more than one process blocked on it, we can
237 defined.  But is very complex to figure it out, since it depends on all
302 Now since mutexes can be defined by user-land applications, we don't want a DOS
344 This is really nice to have, since it allows you to only update a variable
446 or timeout and has left the PI chain.  In either case, the loop is exited, since
475       is OK, since plist_del does nothing if the plist node is not on any
489       since we just grab the mutex's wait_lock. And one could be right.
491       become the task that is being processed in the PI chain, since
538 latency of that critical section (since the low priority process just entered
575 The wait_lock of the mutex is taken since the slow path of unlocking the
616   to update the pending owner's pi_list, since we only worry about processes
622   is no longer on the list of waiters.  This is fine, since the pending owner
633   OK that we set that flag early, since now it is cleared.
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