[PATCH-perfbook 1/4] cpu: Fix typo

[PATCH-perfbook 1/4] cpu: Fix typo

[Johann Klähn]

Signed-off-by: Johann Klähn <johann@jklaehn.de>
---
 cpu/overheads.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpu/overheads.tex b/cpu/overheads.tex
index 84360256..b8a65faa 100644
--- a/cpu/overheads.tex
+++ b/cpu/overheads.tex
@@ -109,7 +109,7 @@ events might ensue:
 	CPUs~0 and~7 might have different values for the same set
 	of variables in the cacheline.
 	This sort of incoherence greatly complicates parallel software,
-	which is why so wise hardware architects avoid it.
+	which is why wise hardware architects avoid it.
 }\QuickQuizEndE
 }
 
-- 
2.34.1

[PATCH-perfbook 2/4] defer: Remove leftover manipulation of bottom bit in hazptr.c

[Johann Klähn]

The bottom bit in this implementation is not (no longer?) used to mark deleted
elements, as is also pointed out in one of the quick questions.

Signed-off-by: Johann Klähn <johann@jklaehn.de>
---
 CodeSamples/defer/hazptr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CodeSamples/defer/hazptr.c b/CodeSamples/defer/hazptr.c
index 2621d407..b84391f4 100644
--- a/CodeSamples/defer/hazptr.c
+++ b/CodeSamples/defer/hazptr.c
@@ -119,7 +119,7 @@ void hazptr_scan()				//\lnlbl{scan:b}
 							//\fcvblank
 		if (!hp)
 			continue;
-		plist[psize++] = (hazptr_head_t *)(hp & ~0x1UL);
+		plist[psize++] = (hazptr_head_t *)hp;
 	}					//\lnlbl{scan:loop:e}
 	smp_mb(); /* ensure freeing happens after scan. */ //\lnlbl{scan:mb2}
 	
-- 
2.34.1

[PATCH-perfbook 3/4] glossary: Fix typo

[Johann Klähn]

Signed-off-by: Johann Klähn <johann@jklaehn.de>
---
 glossary.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glossary.tex b/glossary.tex
index f0cb33e3..46c68bbe 100644
--- a/glossary.tex
+++ b/glossary.tex
@@ -441,7 +441,7 @@
 	The use of algorithms, mechanisms, or techniques that provide
 	non-blocking forward-progress guarantees.
 	NBS is often used in a more restrictive sense of providing one
-	of the stronger forward-progress guarantee, usually wait free or
+	of the stronger forward-progress guarantees, usually wait free or
 	lock free, but sometimes also obstruction free.
 	(See ``Non-blocking''.)
 \item[NUCA:]\glsuseriii{nuca}
-- 
2.34.1

[PATCH-perfbook 4/4] glossary: Use more common definition of RAII

[Johann Klähn]

Cf. https://en.cppreference.com/w/cpp/language/raii or
https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization.

Signed-off-by: Johann Klähn <johann@jklaehn.de>
---
 glsdict.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glsdict.tex b/glsdict.tex
index 194f364d..d1468859 100644
--- a/glsdict.tex
+++ b/glsdict.tex
@@ -237,8 +237,8 @@
 \newacronym{numa}{NUMA}{non-uniform memory architecture}
 \newacronym{qsbr}{QSBR}{quiescent-state-based reclamation}
 \newabbreviation{qsbr:m}{QSBR}{quiescent-state-based-reclamation}
-\newacronym{raii}{RAII}{resource allocation is initialization}
-\newabbreviation{raii:m}{RAII}{resource-allocation-is-initialization}
+\newacronym{raii}{RAII}{resource acquisition is initialization}
+\newabbreviation{raii:m}{RAII}{resource-acquisition-is-initialization}
 \newacronym{rcu}{RCU}{read-copy update}
 \newacronym{smp}{SMP}{symmetric multiprocessing}
 \newabbreviation{smp:m}{SMP}{symmetric-multiprocessing}
-- 
2.34.1

Re: [PATCH-perfbook 4/4] glossary: Use more common definition of RAII

[Paul E. McKenney]

On Tue, Feb 01, 2022 at 09:07:51PM +0100, Johann Klähn wrote:
> Cf. https://en.cppreference.com/w/cpp/language/raii or
> https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization.
> 
> Signed-off-by: Johann Klähn <johann@jklaehn.de>

Huh.  I definitely remember it being "resource allocation is
initialization".  And I do see older uses of "allocation" rather than
"acquisition".  Perhaps it changed once RAII locking entered the picture.

Might as well keep up with the times.  ;-)

I took all but the hazptr change.  I am not necessarily opposed to that
one, but I did want to check whether you had built and tested it.

Thank you!!!

							Thanx, Paul

> ---
>  glsdict.tex | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/glsdict.tex b/glsdict.tex
> index 194f364d..d1468859 100644
> --- a/glsdict.tex
> +++ b/glsdict.tex
> @@ -237,8 +237,8 @@
>  \newacronym{numa}{NUMA}{non-uniform memory architecture}
>  \newacronym{qsbr}{QSBR}{quiescent-state-based reclamation}
>  \newabbreviation{qsbr:m}{QSBR}{quiescent-state-based-reclamation}
> -\newacronym{raii}{RAII}{resource allocation is initialization}
> -\newabbreviation{raii:m}{RAII}{resource-allocation-is-initialization}
> +\newacronym{raii}{RAII}{resource acquisition is initialization}
> +\newabbreviation{raii:m}{RAII}{resource-acquisition-is-initialization}
>  \newacronym{rcu}{RCU}{read-copy update}
>  \newacronym{smp}{SMP}{symmetric multiprocessing}
>  \newabbreviation{smp:m}{SMP}{symmetric-multiprocessing}
> -- 
> 2.34.1
> 

Re: [PATCH-perfbook 4/4] glossary: Use more common definition of RAII

[Johann Klähn]

On Tue, Feb 01, 2022 at 12:38 -0800, Paul E. McKenney wrote:
> I do see older uses of "allocation" rather than "acquisition".
> Perhaps it changed once RAII locking entered the picture.

Yes, perhaps because it's as good an explanation for the “A” if one is
only concerned with memory management?  Apparently the phrase “resource
acquisition is initialization” (though not the acronym) was proposed as
early as ~1990: https://www.stroustrup.com/except89.pdf.  Either way,
“acquisition” seems to have taken over in popularity by now. :-)

> I took all but the hazptr change.  I am not necessarily opposed to that
> one, but I did want to check whether you had built and tested it.

Oh, I forgot to --annotate the patch.  Let me paste my notes here:

To test the change I added the following assert:
| assert((hp & 0x1UL) == 0);
| plist[psize++] = (hazptr_head_t *)hp;

And then I ran the different modes of hazptr and route_hazptr (although
only on my ‘spare time reading’ machine, which has a Intel Pentium 4415Y
with 2 cores/4 threads):
|./hazptr {2,3} {stress,perf,uperf,rperf}
|./route_hazptr {--stresstest,--smoketest,--perftest}

The assertion did not fail.

However, /also before applying the patch/,
• to build route_hazptr I had to work around several “multiple
  definition” linker errors (e.g., for HP in hazptr.h), and
• the “stress” mode of hazptr printed several fields of the form
  “2:15”, even though hazptrtorture.h points out that this should
  only happen for buggy implementations.

(I can have a closer look at some point.)

Thanks
Johann

Re: [PATCH-perfbook 4/4] glossary: Use more common definition of RAII

[Paul E. McKenney]

On Tue, Feb 01, 2022 at 11:16:14PM +0100, Johann Klähn wrote:
> 
> On Tue, Feb 01, 2022 at 12:38 -0800, Paul E. McKenney wrote:
> > I do see older uses of "allocation" rather than "acquisition".
> > Perhaps it changed once RAII locking entered the picture.
> 
> Yes, perhaps because it's as good an explanation for the “A” if one is
> only concerned with memory management?  Apparently the phrase “resource
> acquisition is initialization” (though not the acronym) was proposed as
> early as ~1990: https://www.stroustrup.com/except89.pdf.  Either way,
> “acquisition” seems to have taken over in popularity by now. :-)

I really could not tell you where I first came across RAII.  I did my
one and only professional C++ work in 1990, so about that time.  But I
was not yet much involved in concurrency at that point.  ;-)

> > I took all but the hazptr change.  I am not necessarily opposed to that
> > one, but I did want to check whether you had built and tested it.
> 
> Oh, I forgot to --annotate the patch.  Let me paste my notes here:
> 
> To test the change I added the following assert:
> | assert((hp & 0x1UL) == 0);
> | plist[psize++] = (hazptr_head_t *)hp;
> 
> And then I ran the different modes of hazptr and route_hazptr (although
> only on my ‘spare time reading’ machine, which has a Intel Pentium 4415Y
> with 2 cores/4 threads):
> |./hazptr {2,3} {stress,perf,uperf,rperf}
> |./route_hazptr {--stresstest,--smoketest,--perftest}
> 
> The assertion did not fail.
> 
> However, /also before applying the patch/,
> • to build route_hazptr I had to work around several “multiple
>   definition” linker errors (e.g., for HP in hazptr.h), and
> • the “stress” mode of hazptr printed several fields of the form
>   “2:15”, even though hazptrtorture.h points out that this should
>   only happen for buggy implementations.
> 
> (I can have a closer look at some point.)

I have not gotten to it in the past few days, so please do feel free!

							Thanx, Paul