Browse Source

doc: Emphasize that "toy" RCU requires recursive rwlock

Reported-by: "yangzc@uit.com.cn" <yangzc@uit.com.cn>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Paul E. McKenney 8 years ago
parent
commit
d3d3a3ccc4
1 changed files with 3 additions and 1 deletions
  1. 3 1
      Documentation/RCU/whatisRCU.txt

+ 3 - 1
Documentation/RCU/whatisRCU.txt

@@ -562,7 +562,9 @@ This section presents a "toy" RCU implementation that is based on
 familiar locking primitives.  Its overhead makes it a non-starter for
 familiar locking primitives.  Its overhead makes it a non-starter for
 real-life use, as does its lack of scalability.  It is also unsuitable
 real-life use, as does its lack of scalability.  It is also unsuitable
 for realtime use, since it allows scheduling latency to "bleed" from
 for realtime use, since it allows scheduling latency to "bleed" from
-one read-side critical section to another.
+one read-side critical section to another.  It also assumes recursive
+reader-writer locks:  If you try this with non-recursive locks, and
+you allow nested rcu_read_lock() calls, you can deadlock.
 
 
 However, it is probably the easiest implementation to relate to, so is
 However, it is probably the easiest implementation to relate to, so is
 a good starting point.
 a good starting point.