On Mon, Apr 22, 2019 at 07:19:36AM +0900, Akira Yokosawa wrote:
> On Sun, 21 Apr 2019 11:45:06 -0700, Paul E. McKenney wrote:
> > On Mon, Apr 22, 2019 at 12:25:00AM +0900, Akira Yokosawa wrote:
> >> Hi Paul,
> >>
> >> The sentence shown below as a diff looks incomplete to me.
> >> What is your intention here?
> >
> > Not that! Thank you for catching this!!! Please see below for an
> > attempted fix. Thoughts?
> >
> > I have queued your four patches. My problems are (1) force of habit
> > and (2) failing to remember that comment-only lines are discarded.
>
> And please remember the option "keepcomment=yes" can change the
> behavior. This reminds me that I need to update style guide.
Ah, good point! And please do!
> > I am not all that happy with the #ifdef, but it beats the alternative.
> > But what I did in this case was to just remove the fprintf() in favor
> > of the BUG_ON(). ;-)
>
> Yes, that sounds reasonable.
Very good, I have pushed these changes.
Thanx, Paul
> > ------------------------------------------------------------------------
> >
> > commit 72e774fda87eaead9637d887426b701ec229664d
> > Author: Paul E. McKenney <paulmck@xxxxxxxxxxxxx>
> > Date: Sun Apr 21 11:33:49 2019 -0700
> >
> > defer/hazptr: Fix broken statement of restart location constraints
> >
> > Reported-by: Akira Yokosawa <akiyks@xxxxxxxxx>
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxx>
> >
> > diff --git a/defer/hazptr.tex b/defer/hazptr.tex
> > index 4b61d34d334c..b491c590ae2d 100644
> > --- a/defer/hazptr.tex
> > +++ b/defer/hazptr.tex
> > @@ -239,9 +239,12 @@ Which is a very good thing, because B's successor is the now-freed
> > element~C, which means that Thread~0's subsequent accesses might have
> > resulted in arbitrarily horrible memory corruption, especially if the
> > memory for element~C had since been re-allocated for some other purpose.
> > -Therefore, statically allocated global variables), hazard-pointer
> > -readers must typically restart the full traversal in the face of a
> > -concurrent deletion.
> > +Therefore, hazard-pointer readers must typically restart the full
> > +traversal in the face of a concurrent deletion.
> > +Often the restart must go back to some global (and thus immortal) pointer,
> > +but it is sometimes possible to restart at some intermediate location
> > +if that location is guaranteed to still be live, for example, due to
> > +the current thread holding a lock, a reference count, etc.
>
> Looks good to me!
>
> Thanks, Akira
>
> >
> > \QuickQuiz{}
> > Readers must ``typically'' restart?
> >
>
