On Wed, Jun 21, 2017 at 07:55:34AM +0900, Akira Yokosawa wrote:
> On 2017/06/20 23:28, Akira Yokosawa wrote:
> >>From db0fd6b383b551eabecb12dfa21e42093f338b2f Mon Sep 17 00:00:00 2001
> > From: Akira Yokosawa <akiyks@xxxxxxxxx>
> > Date: Mon, 19 Jun 2017 23:55:31 +0900
> > Subject: [PATCH 2/3] toyrcu: Trivial typo fixes (rcu_idx -> rcu_refcnt)
> >
> > Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
> > ---
> > appendix/toyrcu/toyrcu.tex | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/appendix/toyrcu/toyrcu.tex b/appendix/toyrcu/toyrcu.tex
> > index 79fbe33..a7bf6ca 100644
> > --- a/appendix/toyrcu/toyrcu.tex
> > +++ b/appendix/toyrcu/toyrcu.tex
> > @@ -524,10 +524,10 @@ by complementing the value of \co{rcu_idx}, as in \co{rcu_idx = !rcu_idx}.
> > Suppose that the old value of \co{rcu_idx} was zero, so that the new
> > value is one.
> > New readers that arrive after the complement operation will increment
> > -\co{rcu_idx[1]}, while the old readers that previously incremented
> > -\co{rcu_idx[0]} will decrement \co{rcu_idx[0]} when they exit their
> > +\co{rcu_refcnt[1]}, while the old readers that previously incremented
> > +\co{rcu_refcnt[0]} will decrement \co{rcu_refcnt[0]} when they exit their
> > RCU read-side critical sections.
> > -This means that the value of \co{rcu_idx[0]} will no longer be incremented,
> > +This means that the value of \co{rcu_refcnt[0]} will no longer be incremented,
> > and thus will be monotonically decreasing.\footnote{
> > There is a race condition that this ``monotonically decreasing''
> > statement ignores.
> > @@ -616,11 +616,11 @@ Lines~6 and 19 acquire and release \co{rcu_gp_lock} in order to
> > prevent more than one concurrent instance of \co{synchronize_rcu()}.
> > Lines~7-8 pick up the value of \co{rcu_idx} and complement it,
> > respectively, so that subsequent instances of \co{rcu_read_lock()}
> > -will use a different element of \co{rcu_idx} that did preceding
> > +will use a different element of \co{rcu_refcnt} that did preceding
> > instances.
>
> I have a little trouble with this sentence. Do you mean:
>
> ..., so that subsequent instances of \co{rcu_read_lock()}
> will use a different element of \co{rcu_refcnt} from the one did preceding
> instances.
Just to fully illustrate:
1. Suppose that rcu_idx is initially zero.
2. Any rcu_read_lock() invocations running at this point will
therefore be incrementing rcu_refcnt[0].
3. A synchronize_srcu() instance now complements rcu_idx, so that
its new value is one.
4. Any rcu_read_lock() invocations from step 2 that fetched rcu_idx
before step 3 completed will still increment rcu_refcnt[0].
5. However, any subsequent rcu_read_lock() invocations will instead
increment rcu_refcnt[1]. (At least until the next invocation
of synchronize_rcu().)
Does that help, or am I missing the point of your question?
Thanx, Paul
> ???
>
> Thanks, Akira
> > -Lines~10-12 then wait for the prior element of \co{rcu_idx} to
> > +Lines~10-12 then wait for the prior element of \co{rcu_refcnt} to
> > reach zero, with the memory barrier on line~9 ensuring that the check
> > -of \co{rcu_idx} is not reordered to precede the complementing of
> > +of \co{rcu_refcnt} is not reordered to precede the complementing of
> > \co{rcu_idx}.
> > Lines~13-18 repeat this process, and line~20 ensures that any
> > subsequent reclamation operations are not reordered to precede the
> >
>
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
