Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | RCU Concepts |
2 | ||
3 | ||
4 | The basic idea behind RCU (read-copy update) is to split destructive | |
5 | operations into two parts, one that prevents anyone from seeing the data | |
6 | item being destroyed, and one that actually carries out the destruction. | |
7 | A "grace period" must elapse between the two parts, and this grace period | |
8 | must be long enough that any readers accessing the item being deleted have | |
9 | since dropped their references. For example, an RCU-protected deletion | |
10 | from a linked list would first remove the item from the list, wait for | |
11 | a grace period to elapse, then free the element. See the listRCU.txt | |
12 | file for more information on using RCU with linked lists. | |
13 | ||
14 | ||
15 | Frequently Asked Questions | |
16 | ||
17 | o Why would anyone want to use RCU? | |
18 | ||
19 | The advantage of RCU's two-part approach is that RCU readers need | |
20 | not acquire any locks, perform any atomic instructions, write to | |
21 | shared memory, or (on CPUs other than Alpha) execute any memory | |
22 | barriers. The fact that these operations are quite expensive | |
23 | on modern CPUs is what gives RCU its performance advantages | |
24 | in read-mostly situations. The fact that RCU readers need not | |
25 | acquire locks can also greatly simplify deadlock-avoidance code. | |
26 | ||
27 | o How can the updater tell when a grace period has completed | |
28 | if the RCU readers give no indication when they are done? | |
29 | ||
30 | Just as with spinlocks, RCU readers are not permitted to | |
31 | block, switch to user-mode execution, or enter the idle loop. | |
32 | Therefore, as soon as a CPU is seen passing through any of these | |
33 | three states, we know that that CPU has exited any previous RCU | |
34 | read-side critical sections. So, if we remove an item from a | |
35 | linked list, and then wait until all CPUs have switched context, | |
36 | executed in user mode, or executed in the idle loop, we can | |
37 | safely free up that item. | |
38 | ||
39 | o If I am running on a uniprocessor kernel, which can only do one | |
40 | thing at a time, why should I wait for a grace period? | |
41 | ||
42 | See the UP.txt file in this directory. | |
43 | ||
44 | o How can I see where RCU is currently used in the Linux kernel? | |
45 | ||
46 | Search for "rcu_read_lock", "call_rcu", and "synchronize_kernel". | |
47 | ||
48 | o What guidelines should I follow when writing code that uses RCU? | |
49 | ||
50 | See the checklist.txt file in this directory. | |
51 | ||
52 | o Why the name "RCU"? | |
53 | ||
54 | "RCU" stands for "read-copy update". The file listRCU.txt has | |
55 | more information on where this name came from, search for | |
56 | "read-copy update" to find it. | |
57 | ||
58 | o I hear that RCU is patented? What is with that? | |
59 | ||
60 | Yes, it is. There are several known patents related to RCU, | |
61 | search for the string "Patent" in RTFP.txt to find them. | |
62 | Of these, one was allowed to lapse by the assignee, and the | |
63 | others have been contributed to the Linux kernel under GPL. | |
64 | ||
65 | o Where can I find more information on RCU? | |
66 | ||
67 | See the RTFP.txt file in this directory. |