On Sun, Jun 26, 2022 at 01:34:53PM +0900, Akira Yokosawa wrote: > On Fri, 24 Jun 2022 17:30:53 -0700, Paul E. McKenney wrote: > > On Sat, Jun 25, 2022 at 08:57:35AM +0900, Akira Yokosawa wrote: > >> On Fri, 24 Jun 2022 16:33:16 -0700, Paul E. McKenney wrote: > >>> On Sat, Jun 25, 2022 at 08:12:09AM +0900, Akira Yokosawa wrote: > >>>> Hi Paul, > >>>> > >>>> I find the analogy of Figure 7.11 hard to grasp. > >>>> > >>>> Whether a lock is global or per-instance, the cost of locking > >>>> (saw kerf) is observed only when a CPU/thread does the locking > >>>> operation. > >>>> > >>>> In this figure, does each board represent data elements, not a > >>>> CPU/thread? If this is the case, what does the waste of "saw kerf" > >>>> mean? > >>>> > >>>> What am I missing? > >>>> > >>>> (I hope I am clear enough on what I don't get...) > >>> > >>> It might well be that I am getting too excited about this one. ;-) > >>> > >>> Maybe I need to drop it. At the very least, I need to much more clearly > >>> explain it. > >>> > >>> But... > >>> > >>> Each board represents one lock. The "saw kerf" is the time lost when > >>> releasing that lock and someone else immediately acquiring it. > >>> > >>> Does that help? > >> > >> Well then, why does the left side figure have ten boards? > > > > Ten locks. For example, the single board might correspond to a hash > > table guarded by a single global lock. The ten boards might correspond > > to a hash table with ten buckets, with per-bucket locking. > > Ah, I think I understand what you mean. > > On the "Global" side, there is a per-resource locking mechanism > implemented under the protection of a global lock, whereas locks > on the "Per-Instance" side are implemented independently with > each other. > > Different boards can be acquired in parallel on both sides of the > figure. > > Am I on the same page with you now? Exactly! > > But it is sounding like this analogy might be more confusing than > > enlightening. > > An analogy which needs a lot of explanation might not be a good > analogy... Agreed. So either I figure out a way to ramp an explanation into it, or I drop it. One way to ramp an explanation into it is to discuss locking overheads using hash tables, then go from there. Though at that point, I am not sure how attractive the analogy would be, useful thought it has been to me for these many years. Thank you for reporting this problem, and I will give it some thought. Thanx, Paul
