Messages in this thread | | | Date | Fri, 11 Jun 2021 16:48:29 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] rcu/doc: Add a quick quiz to explain further why we need smp_mb__after_unlock_lock() |
| |
On Sat, Jun 12, 2021 at 12:45:17AM +0200, Frederic Weisbecker wrote: > On Fri, Jun 11, 2021 at 10:25:14AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 11, 2021 at 12:34:32PM +0200, Frederic Weisbecker wrote: > > Glad to help, and I will reach out to you should someone make the mistake > > of insisting that I write something in French. ;-) > > If that can help, we still have frenglish for neutral territories such as airports. > Not easy to master though...
That does sound dangerous! ;-)
> > > > ++-----------------------------------------------------------------------+ > > > > + > > > > This approach must be extended to include idle CPUs, which need > > > > RCU's grace-period memory ordering guarantee to extend to any > > > > RCU read-side critical sections preceding and following the current > > > > How about like this? > > > > +-----------------------------------------------------------------------+ > > | **Quick Quiz**: | > > +-----------------------------------------------------------------------+ > > | But the chain of rcu_node-structure lock acquisitions guarantees | > > | that new readers will see all of the updater's pre-grace-period | > > | accesses and also guarantees that the updater's post-grace-period | > > | accesses will see all of the old reader's accesses. So why do we | > > | need all of those calls to smp_mb__after_unlock_lock()? | > > +-----------------------------------------------------------------------+ > > | **Answer**: | > > +-----------------------------------------------------------------------+ > > | Because we must provide ordering for RCU's polling grace-period | > > | primitives, for example, get_state_synchronize_rcu() and | > > | poll_state_synchronize_rcu(). Consider this code:: | > > | | > > | CPU 0 CPU 1 | > > | ---- ---- | > > | WRITE_ONCE(X, 1) WRITE_ONCE(Y, 1) | > > | g = get_state_synchronize_rcu() smp_mb() | > > | while (!poll_state_synchronize_rcu(g)) r1 = READ_ONCE(X) | > > | continue; | > > | r0 = READ_ONCE(Y) | > > | | > > | RCU guarantees that the outcome r0 == 0 && r1 == 0 will not | > > | happen, even if CPU 1 is in an RCU extended quiescent state | > > | (idle or offline) and thus won't interact directly with the RCU | > > | core processing at all. | > > +-----------------------------------------------------------------------+ > > Very good, thanks a lot :o)
And thank you!
Thanx, Paul
| |