On Sun, Nov 23, 2014 at 5:00 PM, Dennis Ferguson <dennis.c.fergu...@gmail.com> 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?