Commit d3d3a3cc authored by Paul E. McKenney's avatar Paul E. McKenney

doc: Emphasize that "toy" RCU requires recursive rwlock

Reported-by: default avatar"yangzc@uit.com.cn" <yangzc@uit.com.cn>
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parent 93728af0
...@@ -562,7 +562,9 @@ This section presents a "toy" RCU implementation that is based on ...@@ -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.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment