lkml.org 
[lkml]   [2006]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
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/

\
 
 \ /
  Last update: 2006-05-15 10:42    [W:0.039 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site