[PATCH -mm 02/02] Update rt-mutex-design.txt per Randy Dunlap

[Steven Rostedt]

This changes some indentation to rt-mutex-design.txt.

Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx>

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/