On Tue, Jan 04, 2022 at 06:04:14PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 04, 2022 at 06:47:42AM -0500, Elad Lahav wrote:
[ . . . ]
> > > Your response makes me think that I need to explain better what I am
> > > trying to do here. Reading section 9.5 it is not always clear to me what
> > > constitutes a description of RCU and what a description of "RCU in the
> > > Linux kernel". I decided to try and come up with a more abstract
> > > description using the code I attached. It may be just a straw man, but
> > > at least it gives us something to point at while discussing (which I
> > > guess is a redundant definition of a "straw man"...).
>
> Hmmm... Maybe I should add a section following 9.5.1.1 ("Minimal
> Insertion and Deletion") describing the core API:
>
> rcu_read_lock(): Start an RCU read-side critical section.
> rcu_read_unlock(): End an RCU read-side critical section.
> rcu_dereference(): Safely load an RCU-protected pointer.
> synchronize_rcu(): Wait for all pre-existing RCU read-side
> critical sections to complete.
> call_rcu(): Invoke the specified function with the specified
> rcu_head pointer argument after all pre-existing
> RCU read-side critical sections complete.
> rcu_assign_pointer(): Safely update an RCU-protected pointer.
> rcu_dereference_protected(): Safely load an RCU-protected
> pointer within an update. (Just debugging, as you
> can safely do a C-language load. So I will probably
> omit this one.)
>
> Does that help?
Hearing no objections, I added this section and propagated these APIs
into the following sections. I hope that is helpful.
Thanx, Paul
