redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

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>
hifive-unleashed-5.1
Paul E. McKenney 2017-03-28 19:57:45 -07:00
parent 93728af0a1
commit d3d3a3ccc4
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/RCU/whatisRCU.txt
View File

@ -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
real-life use, as does its lack of scalability. It is also unsuitable
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
a good starting point.