Date: Sat, 26 Jul 2014 19:16:20 +0100 From: Mindaugas Rasiukevicius <rm...@netbsd.org>
Taylor R Campbell <riastr...@netbsd.org> wrote: > Date: Sat, 26 Jul 2014 16:48:27 +0100 > From: Mindaugas Rasiukevicius <rm...@netbsd.org> > > http://www.netbsd.org/~rmind/kern_rdlock.c > > That makes a single reader cheap; doesn't make multiple readers > scalable. Huh? Sorry, I misread some of the comments at the top while skimming too quickly. On closer look, I think that basically does the same thing my non-recursive prwlock does, but maybe with less overhead due to pserialize(9) (and three times the amount of code so it's a little harder to see what's going on). In particular: - Read enter waits for writer if any, does some per-CPU bookkeeping. - Read exit notifies writer if there is one waiting. - Writer enter announce itself, waits until no readers on any CPU. - Writer exit wakes waiting readers. If there's no writer, readers need only write to per-CPU structures. Writers must trigger activity on all CPUs and traverse a list of all readers. Many details in how ad's rdlock and my prwlock work are different, but they both follow that same idea. It looks like ad's rdlock is not recursive, so it wouldn't be fit for fstrans(9). I'm not sure how hard it would be to adapt it for that purpose.