Lines Matching refs:owner
102 pi_list of a mutex owner task (described below).
310 Mutex owner and flags
313 The mutex structure contains a pointer to the owner of the mutex. If the
314 mutex is not owned, this owner is set to NULL. Since all architectures
353 The use of rt_mutex_cmpxchg with the flags in the owner field help optimize
414 (de)boosting (the owner of a mutex that a process is blocking on), a flag to
423 that the state of the owner and lock can change when entered into this function.
432 A loop is entered, where task is the owner to be checked for PI changes that
468 Next the owner of the mutex has its pi_lock taken, so we can update the
469 task's entry in the owner's pi_list. If the task is the highest priority
471 from the owner's pi_list, and replace it with the task.
480 task. In this case, the task is removed from the pi_list of the owner,
485 loop, the previous owner of the mutex will be the task that will be
488 Note: One might think that the owner of this mutex might have changed
490 The important thing to remember is that the owner could not have
493 So as long as there is an owner of this mutex that is not the same
502 Isn't this a race condition if the task becomes the new owner?
510 new owner of the mutex. So if the switch of a new owner were to happen
512 wait_lock, the unlocking code would spin on the new owner's pi_lock
524 One of the flags in the owner field of the mutex structure is "Pending Owner".
525 What this means is that an owner was chosen by the process releasing the
526 mutex, but that owner has yet to wake up and actually take the mutex.
542 penalized if it tries to take that mutex again. If the new owner of the
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)
563 fails). Only when the owner field of the mutex is NULL can the lock be
566 If there is contention on the lock, whether it is owned or pending owner
573 the owner.
584 the "Has Waiters" flag of the mutex's owner field. Yes, this could really
585 be false, because if the mutex has no owner, there are no waiters and
589 now, the owner of the mutex can't release the mutex without going into the
591 code currently holds. So setting the "Has Waiters" flag forces the owner
594 Now that we know that we can't have any races with the owner releasing the
596 mutex doesn't have a owner, or if we can steal the mutex from a pending
597 owner. Let's look at the situations we have here.
599 1) Has owner that is pending
602 The mutex has a owner, but it hasn't woken up and the mutex flag
603 "Pending Owner" is set. The first check is to see if the owner isn't the
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
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
625 in try_to_take_rt_mutex if the owner field points to another process.
627 2) No owner
630 If there is no owner (or we successfully stole the lock), we set the owner
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"
674 previous top waiter process (if it exists) from the pi_list of the owner,
675 and add the current process to that list. Since the pi_list of the owner
676 has changed, we call rt_mutex_adjust_prio on the owner to see if the owner
679 If the owner is also blocked on a lock, and had its pi_list changed
681 and run rt_mutex_adjust_prio_chain on the owner, as described earlier.
710 pi_list of the owner. If this process was a high priority process, then
711 the rt_mutex_adjust_prio_chain needs to be executed again on the owner,
720 "Has Waiters" flag of the mutex's owner, we use this to know if we need to
722 waiters, the owner field of the mutex would equal the current process and
723 the mutex can be unlocked by just replacing the owner field with NULL.
725 If the owner field has the "Has Waiters" bit set (or CMPXCHG is not available),
732 do not have CMPXCHG, this is the location that the owner of the mutex will
736 or timeout between the time the owner failed the fast path CMPXCHG check and
738 owner still needs to make this check. If there are no waiters then the mutex
739 owner field is set to NULL, the wait_lock is released and nothing more is
745 On the wake up code, the pi_lock of the current owner is taken. The top
747 as well as the pi_list of the current owner. The task field of the new
748 pending owner's waiter structure is set to NULL, and the owner field of the
749 mutex is set to the new owner with the "Pending Owner" bit set, as well
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
760 of the pending owner.
762 Finally we unlock the pi_lock of the pending owner and wake it up.