On Tue, Apr 7, 2015 at 10:16 PM, Jeff Haran <Jeff.Haran@xxxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
