tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pserialize(9) vs. TAILQ

On Sun, Nov 23, 2014 at 5:00 PM, Dennis Ferguson
<> 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.

I'm lost.  You wrote:

> 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?

Home | Main Index | Thread Index | Old Index