[PATCH] typo at Chp 7.

[PATCH] typo at Chp 7.

[Yubin Ruan]

Hi paul,

I finish chapter 7 and find some typo. Fixed in the patch below.

Yubin

diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
index 9fcbbf9..c7c4ae8 100644
--- a/locking/locking-existence.tex
+++ b/locking/locking-existence.tex
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved. In fact, such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

And here are some more modification to some wording in chapter 7, but I am not
sure whether you like it or not.

Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
lock primitives with atomic instructions(which is what I was doing) is
something that is possible and used in production.

Thanks,
Yubin

diff --git a/locking/locking.tex b/locking/locking.tex
index 14db27d..a9f46f1 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
 	of a signal handler.
 \item	If the application invokes the library function
 	while holding a lock acquired within a given signal
-	handler, then that signal must be blocked every time that the
-	library function is called outside of a signal handler.
+	handler, then that signal must be blocked every time that lock
+    is to be acquired outside of a signal handler.
 \end{enumerate}

 These rules can be enforced by using tools similar to
@@ -2329,7 +2329,7 @@ locking's villainy.
 If there are a very large number of uses of a callback-heavy library,
 it may be wise to again add a parallel-friendly API to the library in
 order to allow existing users to convert their code incrementally.
-Alternatively, some advocate use of transactional memory in these cases.
+Alternatively, some advocate using transactional memory in these cases.
 While the jury is still out on transactional memory,
 Section~\ref{sec:future:Transactional Memory} discusses its strengths and
 weaknesses.

Re: [PATCH] typo at Chp 7.

[Akira Yokosawa]

On 2017/10/27 18:33, Yubin Ruan wrote:
> And here are some more modification to some wording in chapter 7, but I am not
> sure whether you like it or not.
> 
> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> lock primitives with atomic instructions(which is what I was doing) is
> something that is possible and used in production.
> 
> Thanks,
> Yubin
> 
> diff --git a/locking/locking.tex b/locking/locking.tex
> index 14db27d..a9f46f1 100644
> --- a/locking/locking.tex
> +++ b/locking/locking.tex
> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
>  	of a signal handler.
>  \item	If the application invokes the library function
>  	while holding a lock acquired within a given signal
> -	handler, then that signal must be blocked every time that the
> -	library function is called outside of a signal handler.
> +	handler, then that signal must be blocked every time that lock
> +    is to be acquired outside of a signal handler.

The talking point here is library function and signal handler. So something like:

+	handler, then that signal must be blocked every time that one
+	of related library functions is called outside of the signal handler.

Thoughts?

        Thanks, Akira

>  \end{enumerate}
> 
>  These rules can be enforced by using tools similar to
> @@ -2329,7 +2329,7 @@ locking's villainy.
>  If there are a very large number of uses of a callback-heavy library,
>  it may be wise to again add a parallel-friendly API to the library in
>  order to allow existing users to convert their code incrementally.
> -Alternatively, some advocate use of transactional memory in these cases.
> +Alternatively, some advocate using transactional memory in these cases.

Or may be the following?

+Alternatively, some advocate the use of transactional memory in these cases.

Either looks OK to me.

       Thanks, Akira

>  While the jury is still out on transactional memory,
>  Section~\ref{sec:future:Transactional Memory} discusses its strengths and
>  weaknesses.
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> On 2017/10/27 18:33, Yubin Ruan wrote:
> > And here are some more modification to some wording in chapter 7, but I am not
> > sure whether you like it or not.
> > 
> > Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> > lock primitives with atomic instructions(which is what I was doing) is
> > something that is possible and used in production.
> > 
> > Thanks,
> > Yubin
> > 
> > diff --git a/locking/locking.tex b/locking/locking.tex
> > index 14db27d..a9f46f1 100644
> > --- a/locking/locking.tex
> > +++ b/locking/locking.tex
> > @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
> >  	of a signal handler.
> >  \item	If the application invokes the library function
> >  	while holding a lock acquired within a given signal
> > -	handler, then that signal must be blocked every time that the
> > -	library function is called outside of a signal handler.
> > +	handler, then that signal must be blocked every time that lock
> > +    is to be acquired outside of a signal handler.
> 
> The talking point here is library function and signal handler. So something like:
> 
> +	handler, then that signal must be blocked every time that one
> +	of related library functions is called outside of the signal handler.
> 
> Thoughts?

I believe that the major problem is that I didn't really specify the
situation and constraints.  How about the following?

							Thanx, Paul

-----------------------------------------------------------------------

commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Fri Oct 27 16:21:33 2017 -0700

    locking: Clarify explicit avoidance of signal-handler deadlocks
    
    Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/locking/locking.tex b/locking/locking.tex
index 14db27d1148b..025320b294ed 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
 \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
 \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}

-Signal-handler deadlocks can be explicitly avoided as follows:
+Suppose that a given library function is known to acquire locks,
+but does not block signals.
+Suppose further that it is necessary to invoke that function both from
+within and outside of a signal handler, and that it is not permissible
+to modify this library function.
+Of course, if no special action is taken, then if a signal arrives
+while that library function is holding its lock, deadlock can occur
+when the signal handler invokes that same library function,
+which in turn attempts to re-acquire that same lock.
+
+Such deadlocks can be avoided as follows:

 \begin{enumerate}
 \item	If the application invokes the library function from

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> > On 2017/10/27 18:33, Yubin Ruan wrote:
> > > And here are some more modification to some wording in chapter 7, but I am not
> > > sure whether you like it or not.
> > > 
> > > Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> > > lock primitives with atomic instructions(which is what I was doing) is
> > > something that is possible and used in production.
> > > 
> > > Thanks,
> > > Yubin
> > > 
> > > diff --git a/locking/locking.tex b/locking/locking.tex
> > > index 14db27d..a9f46f1 100644
> > > --- a/locking/locking.tex
> > > +++ b/locking/locking.tex
> > > @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
> > >  	of a signal handler.
> > >  \item	If the application invokes the library function
> > >  	while holding a lock acquired within a given signal
> > > -	handler, then that signal must be blocked every time that the
> > > -	library function is called outside of a signal handler.
> > > +	handler, then that signal must be blocked every time that lock
> > > +    is to be acquired outside of a signal handler.
> > 
> > The talking point here is library function and signal handler. So something like:
> > 
> > +	handler, then that signal must be blocked every time that one
> > +	of related library functions is called outside of the signal handler.
> > 
> > Thoughts?
> 
> I believe that the major problem is that I didn't really specify the
> situation and constraints.  How about the following?
> 
> 							Thanx, Paul
> 
> -----------------------------------------------------------------------
> 
> commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Fri Oct 27 16:21:33 2017 -0700
> 
>     locking: Clarify explicit avoidance of signal-handler deadlocks
>     
>     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/locking/locking.tex b/locking/locking.tex
> index 14db27d1148b..025320b294ed 100644
> --- a/locking/locking.tex
> +++ b/locking/locking.tex
> @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
>  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
>  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
>  
> -Signal-handler deadlocks can be explicitly avoided as follows:
> +Suppose that a given library function is known to acquire locks,
> +but does not block signals.
> +Suppose further that it is necessary to invoke that function both from
> +within and outside of a signal handler, and that it is not permissible
> +to modify this library function.
> +Of course, if no special action is taken, then if a signal arrives
> +while that library function is holding its lock, deadlock can occur
> +when the signal handler invokes that same library function,
> +which in turn attempts to re-acquire that same lock.
> +
> +Such deadlocks can be avoided as follows:
>  
>  \begin{enumerate}
>  \item	If the application invokes the library function from
> 


These all look good to me. Thank you Paul.

Yubin

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> > > On 2017/10/27 18:33, Yubin Ruan wrote:
> > > > And here are some more modification to some wording in chapter 7, but I am not
> > > > sure whether you like it or not.
> > > > 
> > > > Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> > > > lock primitives with atomic instructions(which is what I was doing) is
> > > > something that is possible and used in production.
> > > > 
> > > > Thanks,
> > > > Yubin
> > > > 
> > > > diff --git a/locking/locking.tex b/locking/locking.tex
> > > > index 14db27d..a9f46f1 100644
> > > > --- a/locking/locking.tex
> > > > +++ b/locking/locking.tex
> > > > @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
> > > >  	of a signal handler.
> > > >  \item	If the application invokes the library function
> > > >  	while holding a lock acquired within a given signal
> > > > -	handler, then that signal must be blocked every time that the
> > > > -	library function is called outside of a signal handler.
> > > > +	handler, then that signal must be blocked every time that lock
> > > > +    is to be acquired outside of a signal handler.
> > > 
> > > The talking point here is library function and signal handler. So something like:
> > > 
> > > +	handler, then that signal must be blocked every time that one
> > > +	of related library functions is called outside of the signal handler.
> > > 
> > > Thoughts?
> > 
> > I believe that the major problem is that I didn't really specify the
> > situation and constraints.  How about the following?
> > 
> > 							Thanx, Paul
> > 
> > -----------------------------------------------------------------------
> > 
> > commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date:   Fri Oct 27 16:21:33 2017 -0700
> > 
> >     locking: Clarify explicit avoidance of signal-handler deadlocks
> >     
> >     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > diff --git a/locking/locking.tex b/locking/locking.tex
> > index 14db27d1148b..025320b294ed 100644
> > --- a/locking/locking.tex
> > +++ b/locking/locking.tex
> > @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
> >  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
> >  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
> >  
> > -Signal-handler deadlocks can be explicitly avoided as follows:
> > +Suppose that a given library function is known to acquire locks,
> > +but does not block signals.
> > +Suppose further that it is necessary to invoke that function both from
> > +within and outside of a signal handler, and that it is not permissible
> > +to modify this library function.
> > +Of course, if no special action is taken, then if a signal arrives
> > +while that library function is holding its lock, deadlock can occur
> > +when the signal handler invokes that same library function,
> > +which in turn attempts to re-acquire that same lock.
> > +
> > +Such deadlocks can be avoided as follows:
> >  
> >  \begin{enumerate}
> >  \item	If the application invokes the library function from
> 
> These all look good to me. Thank you Paul.

Very good, I will push it out.  May I have your Acked-by?
(As in "Acked-by: Yubin Ruan <ablacktshirt@gmail.com>".)

(If I don't hear otherwise in about 12 hours, I will just push it
out as is.)

							Thanx, Paul

Re: [PATCH] typo at Chp 7.

[Akira Yokosawa]

On 2017/10/28 06:17:03 -0700, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
>> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
>>> On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
>>>> On 2017/10/27 18:33, Yubin Ruan wrote:
>>>>> And here are some more modification to some wording in chapter 7, but I am not
>>>>> sure whether you like it or not.
>>>>>
>>>>> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
>>>>> lock primitives with atomic instructions(which is what I was doing) is
>>>>> something that is possible and used in production.
>>>>>
>>>>> Thanks,
>>>>> Yubin
>>>>>
>>>>> diff --git a/locking/locking.tex b/locking/locking.tex
>>>>> index 14db27d..a9f46f1 100644
>>>>> --- a/locking/locking.tex
>>>>> +++ b/locking/locking.tex
>>>>> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
>>>>>  	of a signal handler.
>>>>>  \item	If the application invokes the library function
>>>>>  	while holding a lock acquired within a given signal
>>>>> -	handler, then that signal must be blocked every time that the
>>>>> -	library function is called outside of a signal handler.
>>>>> +	handler, then that signal must be blocked every time that lock
>>>>> +    is to be acquired outside of a signal handler.
>>>>
>>>> The talking point here is library function and signal handler. So something like:
>>>>
>>>> +	handler, then that signal must be blocked every time that one
>>>> +	of related library functions is called outside of the signal handler.
>>>>
>>>> Thoughts?
>>>
>>> I believe that the major problem is that I didn't really specify the
>>> situation and constraints.  How about the following?
>>>
>>> 							Thanx, Paul
>>>
>>> -----------------------------------------------------------------------
>>>
>>> commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
>>> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>> Date:   Fri Oct 27 16:21:33 2017 -0700
>>>
>>>     locking: Clarify explicit avoidance of signal-handler deadlocks
>>>     
>>>     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
>>>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>>
>>> diff --git a/locking/locking.tex b/locking/locking.tex
>>> index 14db27d1148b..025320b294ed 100644
>>> --- a/locking/locking.tex
>>> +++ b/locking/locking.tex
>>> @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
>>>  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
>>>  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
>>>  
>>> -Signal-handler deadlocks can be explicitly avoided as follows:
>>> +Suppose that a given library function is known to acquire locks,
>>> +but does not block signals.
>>> +Suppose further that it is necessary to invoke that function both from
>>> +within and outside of a signal handler, and that it is not permissible
>>> +to modify this library function.
>>> +Of course, if no special action is taken, then if a signal arrives
>>> +while that library function is holding its lock, deadlock can occur
>>> +when the signal handler invokes that same library function,
>>> +which in turn attempts to re-acquire that same lock.
>>> +
>>> +Such deadlocks can be avoided as follows:
>>>  
>>>  \begin{enumerate}
>>>  \item	If the application invokes the library function from
>>
>> These all look good to me. Thank you Paul.
> 
> Very good, I will push it out.  May I have your Acked-by?
> (As in "Acked-by: Yubin Ruan <ablacktshirt@gmail.com>".)
> 
> (If I don't hear otherwise in about 12 hours, I will just push it
> out as is.)

Paul, please append

Acked-by: Akira Yokosawa <akiyks@gmail.com>

     Thanks, Akira
> 
> 							Thanx, Paul
> 
> 

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sun, Oct 29, 2017 at 07:29:13AM +0900, Akira Yokosawa wrote:
> On 2017/10/28 06:17:03 -0700, Paul E. McKenney wrote:
> > On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
> >> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
> >>> On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> >>>> On 2017/10/27 18:33, Yubin Ruan wrote:
> >>>>> And here are some more modification to some wording in chapter 7, but I am not
> >>>>> sure whether you like it or not.
> >>>>>
> >>>>> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> >>>>> lock primitives with atomic instructions(which is what I was doing) is
> >>>>> something that is possible and used in production.
> >>>>>
> >>>>> Thanks,
> >>>>> Yubin
> >>>>>
> >>>>> diff --git a/locking/locking.tex b/locking/locking.tex
> >>>>> index 14db27d..a9f46f1 100644
> >>>>> --- a/locking/locking.tex
> >>>>> +++ b/locking/locking.tex
> >>>>> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
> >>>>>  	of a signal handler.
> >>>>>  \item	If the application invokes the library function
> >>>>>  	while holding a lock acquired within a given signal
> >>>>> -	handler, then that signal must be blocked every time that the
> >>>>> -	library function is called outside of a signal handler.
> >>>>> +	handler, then that signal must be blocked every time that lock
> >>>>> +    is to be acquired outside of a signal handler.
> >>>>
> >>>> The talking point here is library function and signal handler. So something like:
> >>>>
> >>>> +	handler, then that signal must be blocked every time that one
> >>>> +	of related library functions is called outside of the signal handler.
> >>>>
> >>>> Thoughts?
> >>>
> >>> I believe that the major problem is that I didn't really specify the
> >>> situation and constraints.  How about the following?
> >>>
> >>> 							Thanx, Paul
> >>>
> >>> -----------------------------------------------------------------------
> >>>
> >>> commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
> >>> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>> Date:   Fri Oct 27 16:21:33 2017 -0700
> >>>
> >>>     locking: Clarify explicit avoidance of signal-handler deadlocks
> >>>     
> >>>     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
> >>>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>
> >>> diff --git a/locking/locking.tex b/locking/locking.tex
> >>> index 14db27d1148b..025320b294ed 100644
> >>> --- a/locking/locking.tex
> >>> +++ b/locking/locking.tex
> >>> @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
> >>>  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
> >>>  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
> >>>  
> >>> -Signal-handler deadlocks can be explicitly avoided as follows:
> >>> +Suppose that a given library function is known to acquire locks,
> >>> +but does not block signals.
> >>> +Suppose further that it is necessary to invoke that function both from
> >>> +within and outside of a signal handler, and that it is not permissible
> >>> +to modify this library function.
> >>> +Of course, if no special action is taken, then if a signal arrives
> >>> +while that library function is holding its lock, deadlock can occur
> >>> +when the signal handler invokes that same library function,
> >>> +which in turn attempts to re-acquire that same lock.
> >>> +
> >>> +Such deadlocks can be avoided as follows:
> >>>  
> >>>  \begin{enumerate}
> >>>  \item	If the application invokes the library function from
> >>
> >> These all look good to me. Thank you Paul.
> > 
> > Very good, I will push it out.  May I have your Acked-by?
> > (As in "Acked-by: Yubin Ruan <ablacktshirt@gmail.com>".)
> > 
> > (If I don't hear otherwise in about 12 hours, I will just push it
> > out as is.)
> 
> Paul, please append
> 
> Acked-by: Akira Yokosawa <akiyks@gmail.com>

Done, thank you!

							Thanx, Paul

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

On 10/28/2017 09:17 PM, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
>> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
>>> On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
>>>> On 2017/10/27 18:33, Yubin Ruan wrote:
>>>>> And here are some more modification to some wording in chapter 7, but I am not
>>>>> sure whether you like it or not.
>>>>>
>>>>> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
>>>>> lock primitives with atomic instructions(which is what I was doing) is
>>>>> something that is possible and used in production.
>>>>>
>>>>> Thanks,
>>>>> Yubin
>>>>>
>>>>> diff --git a/locking/locking.tex b/locking/locking.tex
>>>>> index 14db27d..a9f46f1 100644
>>>>> --- a/locking/locking.tex
>>>>> +++ b/locking/locking.tex
>>>>> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
>>>>>  	of a signal handler.
>>>>>  \item	If the application invokes the library function
>>>>>  	while holding a lock acquired within a given signal
>>>>> -	handler, then that signal must be blocked every time that the
>>>>> -	library function is called outside of a signal handler.
>>>>> +	handler, then that signal must be blocked every time that lock
>>>>> +    is to be acquired outside of a signal handler.
>>>>
>>>> The talking point here is library function and signal handler. So something like:
>>>>
>>>> +	handler, then that signal must be blocked every time that one
>>>> +	of related library functions is called outside of the signal handler.
>>>>
>>>> Thoughts?
>>>
>>> I believe that the major problem is that I didn't really specify the
>>> situation and constraints.  How about the following?
>>>
>>> 							Thanx, Paul
>>>
>>> -----------------------------------------------------------------------
>>>
>>> commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
>>> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>> Date:   Fri Oct 27 16:21:33 2017 -0700
>>>
>>>     locking: Clarify explicit avoidance of signal-handler deadlocks
>>>     
>>>     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
>>>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>>
>>> diff --git a/locking/locking.tex b/locking/locking.tex
>>> index 14db27d1148b..025320b294ed 100644
>>> --- a/locking/locking.tex
>>> +++ b/locking/locking.tex
>>> @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
>>>  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
>>>  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
>>>  
>>> -Signal-handler deadlocks can be explicitly avoided as follows:
>>> +Suppose that a given library function is known to acquire locks,
>>> +but does not block signals.
>>> +Suppose further that it is necessary to invoke that function both from
>>> +within and outside of a signal handler, and that it is not permissible
>>> +to modify this library function.
>>> +Of course, if no special action is taken, then if a signal arrives
>>> +while that library function is holding its lock, deadlock can occur
>>> +when the signal handler invokes that same library function,
>>> +which in turn attempts to re-acquire that same lock.
>>> +
>>> +Such deadlocks can be avoided as follows:
>>>  
>>>  \begin{enumerate}
>>>  \item	If the application invokes the library function from
>>
>> These all look good to me. Thank you Paul.
> 
> Very good, I will push it out.  May I have your Acked-by?
> (As in "Acked-by: Yubin Ruan <ablacktshirt@gmail.com>".)
> 
> (If I don't hear otherwise in about 12 hours, I will just push it
> out as is.)


Acked-by: Yubin Ruan <ablacktshirt@gmail.com>

Yubin

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sun, Oct 29, 2017 at 08:15:46AM +0800, Yubin Ruan wrote:
> On 10/28/2017 09:17 PM, Paul E. McKenney wrote:
> > On Sat, Oct 28, 2017 at 09:37:20PM +0800, Yubin Ruan wrote:
> >> On Fri, Oct 27, 2017 at 04:24:08PM -0700, Paul E. McKenney wrote:
> >>> On Sat, Oct 28, 2017 at 12:18:47AM +0900, Akira Yokosawa wrote:
> >>>> On 2017/10/27 18:33, Yubin Ruan wrote:
> >>>>> And here are some more modification to some wording in chapter 7, but I am not
> >>>>> sure whether you like it or not.
> >>>>>
> >>>>> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> >>>>> lock primitives with atomic instructions(which is what I was doing) is
> >>>>> something that is possible and used in production.
> >>>>>
> >>>>> Thanks,
> >>>>> Yubin
> >>>>>
> >>>>> diff --git a/locking/locking.tex b/locking/locking.tex
> >>>>> index 14db27d..a9f46f1 100644
> >>>>> --- a/locking/locking.tex
> >>>>> +++ b/locking/locking.tex
> >>>>> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
> >>>>>  	of a signal handler.
> >>>>>  \item	If the application invokes the library function
> >>>>>  	while holding a lock acquired within a given signal
> >>>>> -	handler, then that signal must be blocked every time that the
> >>>>> -	library function is called outside of a signal handler.
> >>>>> +	handler, then that signal must be blocked every time that lock
> >>>>> +    is to be acquired outside of a signal handler.
> >>>>
> >>>> The talking point here is library function and signal handler. So something like:
> >>>>
> >>>> +	handler, then that signal must be blocked every time that one
> >>>> +	of related library functions is called outside of the signal handler.
> >>>>
> >>>> Thoughts?
> >>>
> >>> I believe that the major problem is that I didn't really specify the
> >>> situation and constraints.  How about the following?
> >>>
> >>> 							Thanx, Paul
> >>>
> >>> -----------------------------------------------------------------------
> >>>
> >>> commit 85025eaceff8cf10c9b674ba70d33dbd012e27ce
> >>> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>> Date:   Fri Oct 27 16:21:33 2017 -0700
> >>>
> >>>     locking: Clarify explicit avoidance of signal-handler deadlocks
> >>>     
> >>>     Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
> >>>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>
> >>> diff --git a/locking/locking.tex b/locking/locking.tex
> >>> index 14db27d1148b..025320b294ed 100644
> >>> --- a/locking/locking.tex
> >>> +++ b/locking/locking.tex
> >>> @@ -2157,7 +2157,17 @@ locks, the strategies in the next section may prove helpful.
> >>>  \subsubsection{Explicitly Avoid Signal-Handler Deadlocks}
> >>>  \label{sec:locking:Explicitly Avoid Signal-Handler Deadlocks}
> >>>  
> >>> -Signal-handler deadlocks can be explicitly avoided as follows:
> >>> +Suppose that a given library function is known to acquire locks,
> >>> +but does not block signals.
> >>> +Suppose further that it is necessary to invoke that function both from
> >>> +within and outside of a signal handler, and that it is not permissible
> >>> +to modify this library function.
> >>> +Of course, if no special action is taken, then if a signal arrives
> >>> +while that library function is holding its lock, deadlock can occur
> >>> +when the signal handler invokes that same library function,
> >>> +which in turn attempts to re-acquire that same lock.
> >>> +
> >>> +Such deadlocks can be avoided as follows:
> >>>  
> >>>  \begin{enumerate}
> >>>  \item	If the application invokes the library function from
> >>
> >> These all look good to me. Thank you Paul.
> > 
> > Very good, I will push it out.  May I have your Acked-by?
> > (As in "Acked-by: Yubin Ruan <ablacktshirt@gmail.com>".)
> > 
> > (If I don't hear otherwise in about 12 hours, I will just push it
> > out as is.)
> 
> 
> Acked-by: Yubin Ruan <ablacktshirt@gmail.com>

Applied, thank you!

							Thanx, Paul

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Fri, Oct 27, 2017 at 05:33:20PM +0800, Yubin Ruan wrote:
> And here are some more modification to some wording in chapter 7, but I am not
> sure whether you like it or not.
> 
> Anyway, chapter 7 makes me feel good ;-) It makes me know that home-brewing a
> lock primitives with atomic instructions(which is what I was doing) is
> something that is possible and used in production.

It most certainly is possible, but it is wise less often than it might
seem.  ;-)

> Thanks,
> Yubin

BTW, I cannot accept patches without a valid Signed-off-by.  As Akira
suggested, please see the FAQ for more details.

> diff --git a/locking/locking.tex b/locking/locking.tex
> index 14db27d..a9f46f1 100644
> --- a/locking/locking.tex
> +++ b/locking/locking.tex
> @@ -2166,8 +2166,8 @@ Signal-handler deadlocks can be explicitly avoided as follows:
>  	of a signal handler.
>  \item	If the application invokes the library function
>  	while holding a lock acquired within a given signal
> -	handler, then that signal must be blocked every time that the
> -	library function is called outside of a signal handler.
> +	handler, then that signal must be blocked every time that lock
> +    is to be acquired outside of a signal handler.
>  \end{enumerate}

I covered this on in my earlier email.

>  These rules can be enforced by using tools similar to
> @@ -2329,7 +2329,7 @@ locking's villainy.
>  If there are a very large number of uses of a callback-heavy library,
>  it may be wise to again add a parallel-friendly API to the library in
>  order to allow existing users to convert their code incrementally.
> -Alternatively, some advocate use of transactional memory in these cases.
> +Alternatively, some advocate using transactional memory in these cases.
>  While the jury is still out on transactional memory,
>  Section~\ref{sec:future:Transactional Memory} discusses its strengths and
>  weaknesses.

And for this one, I am not seeing the problem with the original wording.

							Thanx, Paul

Re: [PATCH] typo at Chp 7.

[Akira Yokosawa]

Hi Yubin,

On 2017/10/27 18:23, Yubin Ruan wrote:
> Hi paul,
> 
> I finish chapter 7 and find some typo. Fixed in the patch below.
> 
> Yubin
> 
> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> index 9fcbbf9..c7c4ae8 100644
> --- a/locking/locking-existence.tex
> +++ b/locking/locking-existence.tex
> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
>  figure, it can be problematic if a given data element can be a member
>  of multiple hash tables or given more-complex data structures such
>  as trees or graphs.
> -These problems can be solved, in fact, such solutions form the basis
> +These problems can be solved. In fact, such solutions form the basis

I'd suggest the following:

+These problems can be solved, in fact, and such solutions form the basis

>  of lock-based software transactional memory
>  implementations~\cite{Shavit95,DaveDice2006DISC}.
>  However,
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 

And please refer to Section 1.5 of perfbook for the process of contributing
patches.

Here is what Paul told me when I submitted my first patch back in April 2016.

On 2016/04/13 1:00, Paul E. McKenney wrote:
> Akira, in the future, please do use "git format-patch" and also please
> use the Linux-kernel preferred format for referencing commits, as shown
> in the updated commit below.  The idea is to use the first 12 digits of
> the SHA-1 commit ID, followed by the subject line in both quotes and
> parentheses.

You can see the archive of the thread at:

    http://www.spinics.net/lists/perfbook/msg00148.html

       Thanks, Akira            

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
> Hi Yubin,
> 
> On 2017/10/27 18:23, Yubin Ruan wrote:
> > Hi paul,
> > 
> > I finish chapter 7 and find some typo. Fixed in the patch below.
> > 
> > Yubin
> > 
> > diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> > index 9fcbbf9..c7c4ae8 100644
> > --- a/locking/locking-existence.tex
> > +++ b/locking/locking-existence.tex
> > @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> >  figure, it can be problematic if a given data element can be a member
> >  of multiple hash tables or given more-complex data structures such
> >  as trees or graphs.
> > -These problems can be solved, in fact, such solutions form the basis
> > +These problems can be solved. In fact, such solutions form the basis
> 
> I'd suggest the following:
> 
> +These problems can be solved, in fact, and such solutions form the basis

How about this?

	Not only can these problems be solved, but the solutions also
	form the basis of lock-based software transactional memory [...].

> >  of lock-based software transactional memory
> >  implementations~\cite{Shavit95,DaveDice2006DISC}.
> >  However,
> > --
> > To unsubscribe from this list: send the line "unsubscribe perfbook" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > .
> > 
> 
> And please refer to Section 1.5 of perfbook for the process of contributing
> patches.
> 
> Here is what Paul told me when I submitted my first patch back in April 2016.
> 
> On 2016/04/13 1:00, Paul E. McKenney wrote:
> > Akira, in the future, please do use "git format-patch" and also please
> > use the Linux-kernel preferred format for referencing commits, as shown
> > in the updated commit below.  The idea is to use the first 12 digits of
> > the SHA-1 commit ID, followed by the subject line in both quotes and
> > parentheses.
> 
> You can see the archive of the thread at:
> 
>     http://www.spinics.net/lists/perfbook/msg00148.html

Please do use this approach if you can, but the delay was instead due
to it taking some time for me to see that the sentence could in fact
be confusing.

							Thanx, Paul

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
> > Hi Yubin,
> > 
> > On 2017/10/27 18:23, Yubin Ruan wrote:
> > > Hi paul,
> > > 
> > > I finish chapter 7 and find some typo. Fixed in the patch below.
> > > 
> > > Yubin
> > > 
> > > diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> > > index 9fcbbf9..c7c4ae8 100644
> > > --- a/locking/locking-existence.tex
> > > +++ b/locking/locking-existence.tex
> > > @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> > >  figure, it can be problematic if a given data element can be a member
> > >  of multiple hash tables or given more-complex data structures such
> > >  as trees or graphs.
> > > -These problems can be solved, in fact, such solutions form the basis
> > > +These problems can be solved. In fact, such solutions form the basis
> > 
> > I'd suggest the following:
> > 
> > +These problems can be solved, in fact, and such solutions form the basis
> 
> How about this?
> 
> 	Not only can these problems be solved, but the solutions also
> 	form the basis of lock-based software transactional memory [...].

Thanks for your suggestion. I think Akira's approach looks more nature to me.
So, let me finish this little patch ;-)

Yubin

--------------------------------------------------------------------------
From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
From: Yubin Ruan <ablacktshirt@gmail.com>
Date: Sat, 28 Oct 2017 16:00:43 +0800
Subject: [PATCH] locking: a typo fixed

Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
---
 locking/locking-existence.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
index 9fcbbf9..2be69d8 100644
--- a/locking/locking-existence.tex
+++ b/locking/locking-existence.tex
@@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
+These problems can be solved, in fact, and such solutions form the basis
 of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
-- 
2.7.4

Re: [PATCH] typo at Chp 7.

[Akira Yokosawa]

On 2017/10/28 17:06, Yubin Ruan wrote:
> On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
>> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
>>> Hi Yubin,
>>>
>>> On 2017/10/27 18:23, Yubin Ruan wrote:
>>>> Hi paul,
>>>>
>>>> I finish chapter 7 and find some typo. Fixed in the patch below.
>>>>
>>>> Yubin
>>>>
>>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
>>>> index 9fcbbf9..c7c4ae8 100644
>>>> --- a/locking/locking-existence.tex
>>>> +++ b/locking/locking-existence.tex
>>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
>>>>  figure, it can be problematic if a given data element can be a member
>>>>  of multiple hash tables or given more-complex data structures such
>>>>  as trees or graphs.
>>>> -These problems can be solved, in fact, such solutions form the basis
>>>> +These problems can be solved. In fact, such solutions form the basis
>>>
>>> I'd suggest the following:
>>>
>>> +These problems can be solved, in fact, and such solutions form the basis
>>
>> How about this?
>>
>> 	Not only can these problems be solved, but the solutions also
>> 	form the basis of lock-based software transactional memory [...].
> 
> Thanks for your suggestion. I think Akira's approach looks more nature to me.
> So, let me finish this little patch ;-)

Well, I think Paul's suggestion is much clearer.

BTW Yubin, your mail has a date field indicating it came from the near future:

> Date: Sat, 28 Oct 2017 16:06:40 +0800

May be time zone setting issue?

      Thanks, Akira

> 
> Yubin
> 
> --------------------------------------------------------------------------
>>From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
> From: Yubin Ruan <ablacktshirt@gmail.com>
> Date: Sat, 28 Oct 2017 16:00:43 +0800
> Subject: [PATCH] locking: a typo fixed
> 
> Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
> ---
>  locking/locking-existence.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> index 9fcbbf9..2be69d8 100644
> --- a/locking/locking-existence.tex
> +++ b/locking/locking-existence.tex
> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
>  figure, it can be problematic if a given data element can be a member
>  of multiple hash tables or given more-complex data structures such
>  as trees or graphs.
> -These problems can be solved, in fact, such solutions form the basis
> +These problems can be solved, in fact, and such solutions form the basis
>  of lock-based software transactional memory
>  implementations~\cite{Shavit95,DaveDice2006DISC}.
>  However,
> 

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

On Sat, Oct 28, 2017 at 10:53:31AM +0900, Akira Yokosawa wrote:
> On 2017/10/28 17:06, Yubin Ruan wrote:
> > On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
> >> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
> >>> Hi Yubin,
> >>>
> >>> On 2017/10/27 18:23, Yubin Ruan wrote:
> >>>> Hi paul,
> >>>>
> >>>> I finish chapter 7 and find some typo. Fixed in the patch below.
> >>>>
> >>>> Yubin
> >>>>
> >>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> >>>> index 9fcbbf9..c7c4ae8 100644
> >>>> --- a/locking/locking-existence.tex
> >>>> +++ b/locking/locking-existence.tex
> >>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> >>>>  figure, it can be problematic if a given data element can be a member
> >>>>  of multiple hash tables or given more-complex data structures such
> >>>>  as trees or graphs.
> >>>> -These problems can be solved, in fact, such solutions form the basis
> >>>> +These problems can be solved. In fact, such solutions form the basis
> >>>
> >>> I'd suggest the following:
> >>>
> >>> +These problems can be solved, in fact, and such solutions form the basis
> >>
> >> How about this?
> >>
> >> 	Not only can these problems be solved, but the solutions also
> >> 	form the basis of lock-based software transactional memory [...].
> > 
> > Thanks for your suggestion. I think Akira's approach looks more nature to me.
> > So, let me finish this little patch ;-)
> 
> Well, I think Paul's suggestion is much clearer.
> 
> BTW Yubin, your mail has a date field indicating it came from the near future:
> 
> > Date: Sat, 28 Oct 2017 16:06:40 +0800
> 
> May be time zone setting issue?

What time zone should I set?

Yubin

> > --------------------------------------------------------------------------
> >>From aede1ef2fe8c5213c8aec9581192c5915e69010c Mon Sep 17 00:00:00 2001
> > From: Yubin Ruan <ablacktshirt@gmail.com>
> > Date: Sat, 28 Oct 2017 16:00:43 +0800
> > Subject: [PATCH] locking: a typo fixed
> > 
> > Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
> > ---
> >  locking/locking-existence.tex | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> > index 9fcbbf9..2be69d8 100644
> > --- a/locking/locking-existence.tex
> > +++ b/locking/locking-existence.tex
> > @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> >  figure, it can be problematic if a given data element can be a member
> >  of multiple hash tables or given more-complex data structures such
> >  as trees or graphs.
> > -These problems can be solved, in fact, such solutions form the basis
> > +These problems can be solved, in fact, and such solutions form the basis
> >  of lock-based software transactional memory
> >  implementations~\cite{Shavit95,DaveDice2006DISC}.
> >  However,
> > 
> 

Re: [PATCH] typo at Chp 7.

[Yubin Ruan]

On Sat, Oct 28, 2017 at 10:53:31AM +0900, Akira Yokosawa wrote:
> On 2017/10/28 17:06, Yubin Ruan wrote:
> > On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
> >> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
> >>> Hi Yubin,
> >>>
> >>> On 2017/10/27 18:23, Yubin Ruan wrote:
> >>>> Hi paul,
> >>>>
> >>>> I finish chapter 7 and find some typo. Fixed in the patch below.
> >>>>
> >>>> Yubin
> >>>>
> >>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> >>>> index 9fcbbf9..c7c4ae8 100644
> >>>> --- a/locking/locking-existence.tex
> >>>> +++ b/locking/locking-existence.tex
> >>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> >>>>  figure, it can be problematic if a given data element can be a member
> >>>>  of multiple hash tables or given more-complex data structures such
> >>>>  as trees or graphs.
> >>>> -These problems can be solved, in fact, such solutions form the basis
> >>>> +These problems can be solved. In fact, such solutions form the basis
> >>>
> >>> I'd suggest the following:
> >>>
> >>> +These problems can be solved, in fact, and such solutions form the basis
> >>
> >> How about this?
> >>
> >> 	Not only can these problems be solved, but the solutions also
> >> 	form the basis of lock-based software transactional memory [...].
> > 
> > Thanks for your suggestion. I think Akira's approach looks more nature to me.
> > So, let me finish this little patch ;-)
> 
> Well, I think Paul's suggestion is much clearer.
> 
> BTW Yubin, your mail has a date field indicating it came from the near future:
> 
> > Date: Sat, 28 Oct 2017 16:06:40 +0800
> 
> May be time zone setting issue?

Thanks Akira, I have correct the time configuration and modify the patch as
follow (as suggested by Paul)

Yubin

-----------------------------------------------------------------------
From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
From: Yubin Ruan <ablacktshirt@gmail.com>
Date: Sat, 28 Oct 2017 17:15:06 +0800
Subject: [PATCH] locking: a typo fixed

Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
---
 locking/locking-existence.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
index 9fcbbf9..6340734 100644
--- a/locking/locking-existence.tex
+++ b/locking/locking-existence.tex
@@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
 figure, it can be problematic if a given data element can be a member
 of multiple hash tables or given more-complex data structures such
 as trees or graphs.
-These problems can be solved, in fact, such solutions form the basis
-of lock-based software transactional memory
+Not only can these problems be solved, but the solutions also form
+the basis of lock-based software transactional memory
 implementations~\cite{Shavit95,DaveDice2006DISC}.
 However,
 Chapter~\ref{chp:Deferred Processing}
-- 
2.7.4

Re: [PATCH] typo at Chp 7.

[Paul E. McKenney]

On Sat, Oct 28, 2017 at 05:16:56PM +0800, Yubin Ruan wrote:
> On Sat, Oct 28, 2017 at 10:53:31AM +0900, Akira Yokosawa wrote:
> > On 2017/10/28 17:06, Yubin Ruan wrote:
> > > On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
> > >> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
> > >>> Hi Yubin,
> > >>>
> > >>> On 2017/10/27 18:23, Yubin Ruan wrote:
> > >>>> Hi paul,
> > >>>>
> > >>>> I finish chapter 7 and find some typo. Fixed in the patch below.
> > >>>>
> > >>>> Yubin
> > >>>>
> > >>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> > >>>> index 9fcbbf9..c7c4ae8 100644
> > >>>> --- a/locking/locking-existence.tex
> > >>>> +++ b/locking/locking-existence.tex
> > >>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
> > >>>>  figure, it can be problematic if a given data element can be a member
> > >>>>  of multiple hash tables or given more-complex data structures such
> > >>>>  as trees or graphs.
> > >>>> -These problems can be solved, in fact, such solutions form the basis
> > >>>> +These problems can be solved. In fact, such solutions form the basis
> > >>>
> > >>> I'd suggest the following:
> > >>>
> > >>> +These problems can be solved, in fact, and such solutions form the basis
> > >>
> > >> How about this?
> > >>
> > >> 	Not only can these problems be solved, but the solutions also
> > >> 	form the basis of lock-based software transactional memory [...].
> > > 
> > > Thanks for your suggestion. I think Akira's approach looks more nature to me.
> > > So, let me finish this little patch ;-)
> > 
> > Well, I think Paul's suggestion is much clearer.
> > 
> > BTW Yubin, your mail has a date field indicating it came from the near future:
> > 
> > > Date: Sat, 28 Oct 2017 16:06:40 +0800
> > 
> > May be time zone setting issue?
> 
> Thanks Akira, I have correct the time configuration and modify the patch as
> follow (as suggested by Paul)

OK, thank you.  But the way you say "as suggested by Paul" is as shown
below, "Suggested-by".  Not at all a big deal in my case, but it is
good to get in practice so that you can help other people get patches
in while still making sure that they get credit.

Also, could you please use "git format-patch" and "git send-email"?
Akira and I can help if the documentation has you confused.  In the
meantime, here are my notes to myself that I use to send out RCU
patches.

If you could redo and resend the patch, I would be very happy to accept it.

------------------------------------------------------------------------
git format-patch -o <dir> -n --subject-prefix="PATCH -tip" <since>[..<until>]

	Create an email-ready patch.  "-n" says to number them.
	Use "git send-email" to send them.

	For typical RCU patch from tip/core/rcu, something like:

		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/rcu" to-mingo
		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH RFC tip/core/rcu" to-mingo
		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/urgent" to-mingo

	For intended submissions, RFC submissions, and bug fixes,
	respectively.

	Then run scripts/checkpatch.pl on each file in /tmp/RCU:

		scripts/checkpatch.pl /tmp/RCU/*

git send-email --no-chain-reply-to --to linux-kernel@vger.kernel.org --cc email1@address1 --cc email2@address2 file1 file2 ...

	For typical RCU patch, check -next conflicts, then something like:

		mutt linux-kernel@vger.kernel.org -c mingo@kernel.org -c jiangshanlai@gmail.com -c dipankar@in.ibm.com -c akpm@linux-foundation.org -c mathieu.desnoyers@efficios.com -c josh@joshtriplett.org -c tglx@linutronix.de -c peterz@infradead.org -c rostedt@goodmis.org -c dhowells@redhat.com -c edumazet@google.com -c fweisbec@gmail.com -c oleg@redhat.com -s '[PATCH tip/core/rcu 0/N] @@@title@@@'

	Then obtain the message-id of the above email, and:

		git send-email  --in-reply-to="@@@" --no-thread --to linux-kernel@vger.kernel.org --cc mingo@kernel.org --cc jiangshanlai@gmail.com --cc dipankar@in.ibm.com --cc akpm@linux-foundation.org --cc mathieu.desnoyers@efficios.com --cc josh@joshtriplett.org --cc tglx@linutronix.de --cc peterz@infradead.org --cc rostedt@goodmis.org --cc dhowells@redhat.com --cc edumazet@google.com --cc fweisbec@gmail.com --cc oleg@redhat.com /tmp/RCU/*

		# git send-email  --in-reply-to="@@@" --no-chain-reply-to --to linux-kernel@vger.kernel.org --cc mingo@kernel.org --cc jiangshanlai@gmail.com --cc dipankar@in.ibm.com --cc akpm@linux-foundation.org --cc mathieu.desnoyers@efficios.com --cc josh@joshtriplett.org --cc tglx@linutronix.de --cc peterz@infradead.org --cc rostedt@goodmis.org --cc dhowells@redhat.com --cc edumazet@google.com --cc dvhart@linux.intel.com --cc fweisbec@gmail.com --cc oleg@redhat.com --cc bobby.prani@gmail.com /tmp/RCU/*
------------------------------------------------------------------------

> Yubin
> 
> -----------------------------------------------------------------------
> >From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
> From: Yubin Ruan <ablacktshirt@gmail.com>
> Date: Sat, 28 Oct 2017 17:15:06 +0800
> Subject: [PATCH] locking: a typo fixed
> 
Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
> ---
>  locking/locking-existence.tex | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
> index 9fcbbf9..6340734 100644
> --- a/locking/locking-existence.tex
> +++ b/locking/locking-existence.tex
> @@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
>  figure, it can be problematic if a given data element can be a member
>  of multiple hash tables or given more-complex data structures such
>  as trees or graphs.
> -These problems can be solved, in fact, such solutions form the basis
> -of lock-based software transactional memory
> +Not only can these problems be solved, but the solutions also form
> +the basis of lock-based software transactional memory
>  implementations~\cite{Shavit95,DaveDice2006DISC}.
>  However,
>  Chapter~\ref{chp:Deferred Processing}
> -- 
> 2.7.4
> 

Re: [PATCH] typo at Chp 7.

[Akira Yokosawa]

On 2017/10/28 06:23:17 -0700, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 05:16:56PM +0800, Yubin Ruan wrote:
>> On Sat, Oct 28, 2017 at 10:53:31AM +0900, Akira Yokosawa wrote:
>>> On 2017/10/28 17:06, Yubin Ruan wrote:
>>>> On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
>>>>> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
>>>>>> Hi Yubin,
>>>>>>
>>>>>> On 2017/10/27 18:23, Yubin Ruan wrote:
>>>>>>> Hi paul,
>>>>>>>
>>>>>>> I finish chapter 7 and find some typo. Fixed in the patch below.
>>>>>>>
>>>>>>> Yubin
>>>>>>>
>>>>>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
>>>>>>> index 9fcbbf9..c7c4ae8 100644
>>>>>>> --- a/locking/locking-existence.tex
>>>>>>> +++ b/locking/locking-existence.tex
>>>>>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
>>>>>>>  figure, it can be problematic if a given data element can be a member
>>>>>>>  of multiple hash tables or given more-complex data structures such
>>>>>>>  as trees or graphs.
>>>>>>> -These problems can be solved, in fact, such solutions form the basis
>>>>>>> +These problems can be solved. In fact, such solutions form the basis
>>>>>>
>>>>>> I'd suggest the following:
>>>>>>
>>>>>> +These problems can be solved, in fact, and such solutions form the basis
>>>>>
>>>>> How about this?
>>>>>
>>>>> 	Not only can these problems be solved, but the solutions also
>>>>> 	form the basis of lock-based software transactional memory [...].
>>>>
>>>> Thanks for your suggestion. I think Akira's approach looks more nature to me.
>>>> So, let me finish this little patch ;-)
>>>
>>> Well, I think Paul's suggestion is much clearer.
>>>
>>> BTW Yubin, your mail has a date field indicating it came from the near future:
>>>
>>>> Date: Sat, 28 Oct 2017 16:06:40 +0800
>>>
>>> May be time zone setting issue?
>>
>> Thanks Akira, I have correct the time configuration and modify the patch as
>> follow (as suggested by Paul)
> 
> OK, thank you.  But the way you say "as suggested by Paul" is as shown
> below, "Suggested-by".  Not at all a big deal in my case, but it is
> good to get in practice so that you can help other people get patches
> in while still making sure that they get credit.
> 
> Also, could you please use "git format-patch" and "git send-email"?
> Akira and I can help if the documentation has you confused.

I'm not sure I can help in the use of "git send-email".
Looks like Yubin did use "git format-patch" and appended the patch below
the "-----------" line, which is not recognized as scissors by "git am".
A line of "----8<-----" could be used instead.

>                                                             In the
> meantime, here are my notes to myself that I use to send out RCU
> patches.
> 
> If you could redo and resend the patch, I would be very happy to accept it.
> 
> ------------------------------------------------------------------------
> git format-patch -o <dir> -n --subject-prefix="PATCH -tip" <since>[..<until>]
> 
> 	Create an email-ready patch.  "-n" says to number them.
> 	Use "git send-email" to send them.
> 
> 	For typical RCU patch from tip/core/rcu, something like:
> 
> 		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/rcu" to-mingo
> 		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH RFC tip/core/rcu" to-mingo
> 		git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/urgent" to-mingo
> 
> 	For intended submissions, RFC submissions, and bug fixes,
> 	respectively.
> 
> 	Then run scripts/checkpatch.pl on each file in /tmp/RCU:
> 
> 		scripts/checkpatch.pl /tmp/RCU/*
> 
> git send-email --no-chain-reply-to --to linux-kernel@vger.kernel.org --cc email1@address1 --cc email2@address2 file1 file2 ...
> 
> 	For typical RCU patch, check -next conflicts, then something like:
> 
> 		mutt linux-kernel@vger.kernel.org -c mingo@kernel.org -c jiangshanlai@gmail.com -c dipankar@in.ibm.com -c akpm@linux-foundation.org -c mathieu.desnoyers@efficios.com -c josh@joshtriplett.org -c tglx@linutronix.de -c peterz@infradead.org -c rostedt@goodmis.org -c dhowells@redhat.com -c edumazet@google.com -c fweisbec@gmail.com -c oleg@redhat.com -s '[PATCH tip/core/rcu 0/N] @@@title@@@'
> 
> 	Then obtain the message-id of the above email, and:
> 
> 		git send-email  --in-reply-to="@@@" --no-thread --to linux-kernel@vger.kernel.org --cc mingo@kernel.org --cc jiangshanlai@gmail.com --cc dipankar@in.ibm.com --cc akpm@linux-foundation.org --cc mathieu.desnoyers@efficios.com --cc josh@joshtriplett.org --cc tglx@linutronix.de --cc peterz@infradead.org --cc rostedt@goodmis.org --cc dhowells@redhat.com --cc edumazet@google.com --cc fweisbec@gmail.com --cc oleg@redhat.com /tmp/RCU/*
> 
> 		# git send-email  --in-reply-to="@@@" --no-chain-reply-to --to linux-kernel@vger.kernel.org --cc mingo@kernel.org --cc jiangshanlai@gmail.com --cc dipankar@in.ibm.com --cc akpm@linux-foundation.org --cc mathieu.desnoyers@efficios.com --cc josh@joshtriplett.org --cc tglx@linutronix.de --cc peterz@infradead.org --cc rostedt@goodmis.org --cc dhowells@redhat.com --cc edumazet@google.com --cc dvhart@linux.intel.com --cc fweisbec@gmail.com --cc oleg@redhat.com --cc bobby.prani@gmail.com /tmp/RCU/*
> ------------------------------------------------------------------------
> 
>> Yubin
>>
>> -----------------------------------------------------------------------
>> >From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
>> From: Yubin Ruan <ablacktshirt@gmail.com>
>> Date: Sat, 28 Oct 2017 17:15:06 +0800
>> Subject: [PATCH] locking: a typo fixed

This change is not a simple "typo fix" any more, so I think the commit title
should be reworded to something like "locking: Fix syntactic ambiguity".

And please append my acked-by:

      Thanks, Akira

>>
> Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Akira Yokosawa <akiyks@gmail.com>
>> Signed-off-by: Yubin Ruan <ablacktshirt@gmail.com>
>> ---
>>  locking/locking-existence.tex | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
>> index 9fcbbf9..6340734 100644
>> --- a/locking/locking-existence.tex
>> +++ b/locking/locking-existence.tex
>> @@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
>>  figure, it can be problematic if a given data element can be a member
>>  of multiple hash tables or given more-complex data structures such
>>  as trees or graphs.
>> -These problems can be solved, in fact, such solutions form the basis
>> -of lock-based software transactional memory
>> +Not only can these problems be solved, but the solutions also form
>> +the basis of lock-based software transactional memory
>>  implementations~\cite{Shavit95,DaveDice2006DISC}.
>>  However,
>>  Chapter~\ref{chp:Deferred Processing}
>> -- 
>> 2.7.4
>>
> 
>