Messages in this thread Patch in this message | | | Date | Mon, 15 May 2006 04:39:49 -0400 (EDT) | From | Steven Rostedt <> | Subject | [PATCH -mm 02/02] Update rt-mutex-design.txt per Randy Dunlap |
| |
This changes some indentation to rt-mutex-design.txt.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Index: linux-2.6.17-rc3-mm1/Documentation/rt-mutex-design.txt =================================================================== --- linux-2.6.17-rc3-mm1.orig/Documentation/rt-mutex-design.txt 2006-05-15 04:04:48.000000000 -0400 +++ linux-2.6.17-rc3-mm1/Documentation/rt-mutex-design.txt 2006-05-15 04:04:52.000000000 -0400 @@ -596,47 +596,47 @@ mutex, we check to see if we can take th mutex doesn't have a owner, or if we can steal the mutex from a pending owner. Let's look at the situations we have here.
-1) Has owner that is pending ----------------------------- -The mutex has a owner, but it hasn't woken up and the mutex flag -"Pending Owner" is set. The first check is to see if the owner isn't the -current task. This is because this function is also used for the pending -owner to grab the mutex. When a pending owner wakes up, it checks to see -if it can take the mutex, and this is done if the owner is already set to -itself. If so, we succeed and leave the function, clearing the "Pending -Owner" bit. - -If the pending owner is not current, we check to see if the current priority is -higher than the pending owner. If not, we fail the function and return. - -There's also something special about a pending owner. That is a pending owner -is never blocked on a mutex. So there is no PI chain to worry about. It also -means that if the mutex doesn't have any waiters, there's no accounting needed -to update the pending owner's pi_list, since we only worry about processes -blocked on the current mutex. - -If there are waiters on this mutex, and we just stole the ownership, we need -to take the top waiter, remove it from the pi_list of the pending owner, and -add it to the current pi_list. Note that at this moment, the pending owner -is no longer on the list of waiters. This is fine, since the pending owner -would add itself back when it realizes that it had the ownership stolen -from itself. When the pending owner tries to grab the mutex, it will fail -in try_to_take_rt_mutex if the owner field points to another process. - -2) No owner ------------ - -If there is no owner (or we successfully stole the lock), we set the owner -of the mutex to current, and set the flag of "Has Waiters" if the current -mutex actually has waiters, or we clear the flag if it doesn't. See, it was -OK that we set that flag early, since now it is cleared. - -3) Failed to grab ownership ---------------------------- - -The most interesting case is when we fail to take ownership. This means that -there exists an owner, or there's a pending owner with equal or higher -priority than the current task. + 1) Has owner that is pending + ---------------------------- + The mutex has a owner, but it hasn't woken up and the mutex flag + "Pending Owner" is set. The first check is to see if the owner isn't the + current task. This is because this function is also used for the pending + owner to grab the mutex. When a pending owner wakes up, it checks to see + if it can take the mutex, and this is done if the owner is already set to + itself. If so, we succeed and leave the function, clearing the "Pending + Owner" bit. + + If the pending owner is not current, we check to see if the current priority is + higher than the pending owner. If not, we fail the function and return. + + There's also something special about a pending owner. That is a pending owner + is never blocked on a mutex. So there is no PI chain to worry about. It also + means that if the mutex doesn't have any waiters, there's no accounting needed + to update the pending owner's pi_list, since we only worry about processes + blocked on the current mutex. + + If there are waiters on this mutex, and we just stole the ownership, we need + to take the top waiter, remove it from the pi_list of the pending owner, and + add it to the current pi_list. Note that at this moment, the pending owner + is no longer on the list of waiters. This is fine, since the pending owner + would add itself back when it realizes that it had the ownership stolen + from itself. When the pending owner tries to grab the mutex, it will fail + in try_to_take_rt_mutex if the owner field points to another process. + + 2) No owner + ----------- + + If there is no owner (or we successfully stole the lock), we set the owner + of the mutex to current, and set the flag of "Has Waiters" if the current + mutex actually has waiters, or we clear the flag if it doesn't. See, it was + OK that we set that flag early, since now it is cleared. + + 3) Failed to grab ownership + --------------------------- + + The most interesting case is when we fail to take ownership. This means that + there exists an owner, or there's a pending owner with equal or higher + priority than the current task.
We'll continue on the failed case.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |