Re: pserialize(9) vs. TAILQ

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Sun, Nov 23, 2014 at 5:00 PM, Dennis Ferguson
<dennis.c.ferguson%gmail.com@localhost> wrote:
> I was happy with no barrier in the reader when I thought providing
> support for the DEC Alpha architecture's unique cache quirk wasn't
> necessary.  When it turned out support for the Alpha was necessary
> the reader needed to have a barrier inserted that looks like it gets
> executed after every read pointer read.  Note, however, that this is
> a barrier which does nothing at all on any machine other than an
> Alpha. Nothing has changed, nothing has been contradicted, no cost
> has been added to readers.  Taylor might like to see barrier
> operations paired up in C code but there is no pairing at the
> hardware instruction level.  The reader barrier has no cost on any
> machine other than the Alpha, the only machine which has an
> architectural requirement to generate an instruction there.
(snip)

I'm lost.  You wrote:

http://mail-index.netbsd.org/tech-kern/2014/11/20/msg018048.html

> The conclusion is that while the current TAILQ_REMOVE() macro will work
> unchanged to maintain a list with concurrent readers (given no requirement
> to run on an MP DEC Alpha) the TAILQ_INSERT_*() macros will not, even
> though they look correct.  The mutex and/or the use of pserialize() does
> nothing to change this.  If you want to insert things into a TAILQ list
> without blocking concurrent readers you must use alternative macros that
> have membar_producer() calls in the right spots.

- TAILQ_REMOVE() will work (except on Alpha)
- TAILQ_INSERT_*() will not (on Alpha and some others)
  - TAILQ_INSERT_*() need membar_producer()
  - TAILQ_FOREACH() needs membar_consumer()

Am I reading English correctly?