Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Read-copy-update
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Sample RCU interface== RCU is available in a number of operating systems and was added to the [[Linux kernel]] in October 2002. User-level implementations such as [http://lttng.org/urcu liburcu] are also available.<ref>{{Cite thesis | last = Desnoyers | first = Mathieu | title = Low-Impact Operating System Tracing | url = http://www.lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf | journal = Γcole Polytechnique de Montreal | date = December 2009 }}</ref> The implementation of RCU in version 2.6 of the Linux kernel is among the better-known RCU implementations and will be used as an inspiration for the RCU API in the remainder of this article. The core API ([[Application Programming Interface]]) is quite small:<ref>{{cite web | last = McKenney | first = Paul E. | title = RCU part 3: the RCU API | publisher = [[Linux Weekly News]] | date = January 17, 2008 | url = https://lwn.net/Articles/264090/ | access-date = September 24, 2010 }}</ref> * rcu_read_lock(): Marks an RCU-protected data structure so that it won't be reclaimed for the full duration of that critical section. * rcu_read_unlock(): Used by a reader to inform the reclaimer that the reader is exiting an RCU read-side critical section. Note that RCU read-side critical sections may be nested and/or overlapping. * synchronize_rcu(): Blocks until all pre-existing RCU read-side critical sections on all CPUs have completed. Note that <code>synchronize_rcu</code> will ''not'' necessarily wait for any subsequent RCU read-side critical sections to complete. For example, consider the following sequence of events: <pre> CPU 0 CPU 1 CPU 2 ----------------- ------------------------- --------------- 1. rcu_read_lock() 2. enters synchronize_rcu() 3. rcu_read_lock() 4. rcu_read_unlock() 5. exits synchronize_rcu() 6. rcu_read_unlock() </pre> :Since <code>synchronize_rcu</code> is the API that must figure out when readers are done, its implementation is key to RCU. For RCU to be useful in all but the most read-intensive situations, <code>synchronize_rcu</code>'s overhead must also be quite small. :Alternatively, instead of blocking, synchronize_rcu may register a callback to be invoked after all ongoing RCU read-side critical sections have completed. This callback variant is called <code>call_rcu</code> in the Linux kernel. * rcu_assign_pointer(): The updater uses this function to assign a new value to an RCU-protected pointer, in order to safely communicate the change in value from the updater to the reader. This function returns the new value, and also executes any [[memory barrier]] instructions required for a given CPU architecture. Perhaps more importantly, it serves to document which pointers are protected by RCU. * rcu_dereference(): The reader uses <code>rcu_dereference</code> to fetch an RCU-protected pointer, which returns a value that may then be safely dereferenced. It also executes any directives required by the compiler or the CPU, for example, a volatile cast for gcc, a memory_order_consume load for C/C++11 or the memory-barrier instruction required by the old DEC Alpha CPU. The value returned by <code>rcu_dereference</code> is valid only within the enclosing RCU read-side critical section. As with <code>rcu_assign_pointer</code>, an important function of <code>rcu_dereference</code> is to document which pointers are protected by RCU. [[File:Rcu api.jpg|thumb|upright=2|RCU API communications between the reader, updater, and reclaimer]] The diagram on the right shows how each API communicates among the reader, updater, and reclaimer. The RCU infrastructure observes the time sequence of <code>rcu_read_lock</code>, <code>rcu_read_unlock</code>, <code>synchronize_rcu</code>, and <code>call_rcu</code> invocations in order to determine when (1) <code>synchronize_rcu</code> invocations may return to their callers and (2) <code>call_rcu</code> callbacks may be invoked. Efficient implementations of the RCU infrastructure make heavy use of batching in order to amortize their overhead over many uses of the corresponding APIs.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)