Re: [Not a patch] Possible incomplete sentence/clause in defer/hazptr

["Paul E. McKenney" <paulmck@linux.ibm.com>]

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@linux.ibm.com>
> > Date:   Sun Apr 21 11:33:49 2019 -0700
> > 
> >     defer/hazptr: Fix broken statement of restart location constraints
> >     
> >     Reported-by: Akira Yokosawa <akiyks@gmail.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > 
> > 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?
> > 
>