maybe dumb question about RCU

[Andev]

On Tue, Apr 7, 2015 at 10:16 PM, Jeff Haran <Jeff.Haran at citrix.com> wrote:
> Disabling preemption would prevent a writer on the same core as the reader from changing the pointer in the read critical section.
>
> But what happens if the writer is running on another core of a multi-core system?
>
> Seems like a writer on another core could still get in there and change the value of the pointer between the two rcu_dereference() calls in the reader.

Think of it this way. You have a global variable which is being
managed by RCU i.e., will be accessed and modified using rcu_*() API.

When you enter a rcu read critical section using rcu_read_lock(),
conceptually what happens is you create a copy of that variable say
global_v1. As long as you are within the critical section, any
references to global will return the value of global_v1.

Now let's say that a write has modified this variable. If another read
critical section starts after this modification, the version in that
read critical section will be global_v2 which has the new value of
global. Bear in mind that the first read critical section is not yet
complete, so RCU needs to ensure that both copies of global still
exist. Again, as long as this read critical section is active, it will
get the new value from global_v2.

At a later point, the first read critical section will complete and
RCU will then delete/remove global_v1 as this is no longer necessary.

There are some details missing, but this is the crux of the RCU concept.

-- 
Andev