Re: pserialize(9) vs. TAILQ

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

   Date: Wed, 19 Nov 2014 17:11:18 +0800
   From: Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>

   On 19 Nov, 2014, at 01:53 , Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
   > The one tricky detail is that after a reader has fetched the tqe_next
   > pointer, it must issue a membar_consumer before dereferencing the
   > pointer: otherwise there is no guarantee about the order in which the
   > CPU will fetch the tqe_next pointer and its contents (which it may
   > have cached).

   I don't think it is correct to use a membar_consumer().

It is certainly /correct/.  It may not be /necessary/ in some
architectures that provide more guarantees about load ordering than
are written in the program without membar_consumer.

   Since most machines don't need any barrier here it would be extremely
   inefficient to add a membar_consumer() since that would make all machines
   pay for the idiosyncrasies unique to the DEC Alpha.

We could invent a membar_datadep_consumer for this case, and make it a
no-op on everything other than Alpha until another CPU designer
relaxes the memory ordering.  The intent of the code is clearer with
the memory barrier, and it emphasizes the need for a paired
membar_producer elsewhere.