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
