Re: pserialize(9) vs. TAILQ

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Tue, 25 Nov 2014 00:33:11 +0900
   From: Masao Uebayashi <uebayasi%gmail.com@localhost>

   I think I understand the context.  membar_consumer() can be omitted
   because forward list iteration is (happen to be) "dependent-load"
   (except on Alpha).

Just to clarify a tiny bit:  TAILQ_FOREACH uses data-dependent loads,
no matter what CPU architecture it runs on.  A data-dependent load is
anything like what CPU 2 is doing here:

CPU 1                   CPU 2

A = 0
A = 5
membar_producer()
*pp = &A
                        p = *pp
                        v = *p          <--- Data-dependent load:
                                             load address depends on
                                             data from previous load.

On most CPU architectures, v is guaranteed to be 5; on alpha, if you
want v to be 5, you must insert a membar_consumer between `p = *pp'
and `v = *p'.

Writing membar_datadep_consumer there would (a) add no overhead to
CPUs that provide the guarantee, (b) make the code work on CPUs that
don't, and (c) explain to anyone who is reading the code that
interprocessor memory ordering is important here.

I say `data-dependent load', not just `dependent load', because there
are also control-dependent loads, as in

if (ok[i])
	v = value[i];

which require membar_consumer on CPUs other than alpha.

   My confusion came from that I thought memory ordering of load is more
   flexible in general.  I also didn't quite understand "dependent-load".
   I have been only reading NetBSD kernel code to learn memory ordering;
   and I believe, nothing in the tree utilize this topologycal
   "dependent-load".  I may be missing something though.

We do have at least one use of nontrivial data-dependent loads
in-tree, in pcq(9), as Dennis noted.

   On Mon, Nov 24, 2014 at 11:21 PM, Taylor R Campbell
   <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
   > To clarify this situation, I added _PSZ versions of all of these in
   > the patch I sent earlier that will
   >
   > (a) do the right thing everywhere, and
   > (b) mark where you're sharing a queue with pserialize.

   I'm still not sure what part is really specific to pserialize(9) or not.

You're right that it's not really specific to pserialize, but it is
designed to be safe to use with pserialize, and most uses would
probably be written with pserialize.