lkml.org 
[lkml]   [2021]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rcu/doc: Add a quick quiz to explain further why we need smp_mb__after_unlock_lock()
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...

>
> > > ++-----------------------------------------------------------------------+
> > > +
> > > 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)

\
 
 \ /
  Last update: 2021-06-12 00:45    [W:0.059 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site