Re: pserialize(9) vs. TAILQ

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

On Wed, Nov 19, 2014 at 1:05 AM, Dennis Ferguson
<dennis.c.ferguson%gmail.com@localhost> wrote:
>
> On 18 Nov, 2014, at 22:13 , Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
>> In the TAILQ case, where readers iterate a list by TAILQ_FOREACH(),
>> TAILQ_REMOVE() is safely used as the update operation, because:
>>
>> - Readers only see tqe_next in TAILQ_FOREACH(), and
>> - Pointer assignment (done in TAILQ_REMOVE()) is atomic.
>>
>> If this is correct, pserialize(9) should be updated to be clearer;
>> probably this TAILQ example is worth being added there.
>
> I don't think TAILQ is a good example for this.  While TAILQ_REMOVE()
> will work, none of the TAILQ_INSERT_*() macros can be reliably used
> with concurrent readers so it isn't clear how the list you are
> removing stuff from could have been built.

If there is a promise that readers iterate list only in forward
direction (using tqe_next / tqh_first), the actual update operation by
writers is the pointer assignment to link the new element.  (Note that
next pointer in the new element is not visible until it is linked.)
This is common to any list, and TAILQ is not an exception.

> Also, the TAILQ macros depend on a type pun fairly similar to the one
> that did in the CIRCLEQ macros and hence have a lifetime which extends
> only to some future version of the compiler smart enough to recognize
> that and miscompile them.  I think new code, and new man page text,
> should probably avoid using the macros to keep from making the eventual
> problem with them bigger than it already is.

No comment about this part. :)  Any better suggestion?