[PATCH] defer/refcnt: Another typo fix

[PATCH] defer/refcnt: Another typo fix

[Akira Yokosawa]

 From ae44b15b34f4cba077d0c49e7416f66681895a3d Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Tue, 12 Jul 2016 00:33:08 +0900
Subject: [PATCH] defer/refcnt: Another typo fix

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
  defer/refcnt.tex | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/defer/refcnt.tex b/defer/refcnt.tex
index 8dfa8fe..76ebf4d 100644
--- a/defer/refcnt.tex
+++ b/defer/refcnt.tex
@@ -267,7 +267,7 @@ Figure~\ref{fig:defer:Pre-BSD Packet Routing List}:
  
  The problem is that the reference count is located in the object
  to be protected, but that means that there is no protection during
-the instant in time when the reference count itself if being acquired!
+the instant in time when the reference count itself is being acquired!
  This is the reference-counting counterpart of a locking issue noted
  by Gamsa et al.~\cite{Gamsa99}.
  One could imagine using a global lock or reference count to protect
-- 
1.9.1

Re: [PATCH] defer/refcnt: Another typo fix

[Paul E. McKenney]

On Tue, Jul 12, 2016 at 12:36:29AM +0900, Akira Yokosawa wrote:
> From ae44b15b34f4cba077d0c49e7416f66681895a3d Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiyks@gmail.com>
> Date: Tue, 12 Jul 2016 00:33:08 +0900
> Subject: [PATCH] defer/refcnt: Another typo fix
> 
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>

Good eyes!  Applied and pushed both, thank you!

							Thanx, Paul

> ---
>  defer/refcnt.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/defer/refcnt.tex b/defer/refcnt.tex
> index 8dfa8fe..76ebf4d 100644
> --- a/defer/refcnt.tex
> +++ b/defer/refcnt.tex
> @@ -267,7 +267,7 @@ Figure~\ref{fig:defer:Pre-BSD Packet Routing List}:
>  The problem is that the reference count is located in the object
>  to be protected, but that means that there is no protection during
> -the instant in time when the reference count itself if being acquired!
> +the instant in time when the reference count itself is being acquired!
>  This is the reference-counting counterpart of a locking issue noted
>  by Gamsa et al.~\cite{Gamsa99}.
>  One could imagine using a global lock or reference count to protect
> -- 
> 1.9.1
>