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
