Re: pserialize(9) vs. TAILQ

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

On Wed, Nov 19, 2014 at 2:49 PM, Dennis Ferguson
<dennis.c.ferguson%gmail.com@localhost> wrote:
> That's very true, but the code is only correct if the writes occur
> in the order the C code has them written (i.e. tqe_next in the
> new element is written before writing the tqe_next of the existing
> list element to point at it).  To ensure the compiler or the
> cache hardware doesn't reorder those writes it needs a write barrier
> inserted to enforce the order as written.

Yes, in the pserialize(9) + TAILQ() case, everything except tqe_next
is only written by writers, and protected with a mutex, which ensures
(implies) ordering.  What is ordered by what has to be clearly
documented.

> Making sure there are memory barriers where they are needed is the
> hardest part of writing data structure update code designed to operate
> with concurrent readers, since the C code still looks perfectly correct
> without them.

Agreed.  The current manual (membar_*(9)) and existing code are not
good for learners (like me).

I always wonder why membar(9) functions don't take arguments to
clarify the ordering of objects.  Even if those object addresses have
no meaning for CPUs, declaring the intended objects, ordered either
before/after the barrier, should help help code to be clearer.