Aliasing issue with TAILQ on ppc64 ?

[Attilio Rao]

On 9/18/12, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message
> <CAJ-FndAwUDJsJZNqihzdfz60UEhS75oOYijjb7LAzT+wx1V6DA at mail.gmail.com>
> , Attilio Rao writes:
>
>>Yep, it likely means you need to use compiler memory barriers then.
>>I didn't look into details the implementation of TAILQ (but I can if
>>you want)
>
> Yes, It might be helpful if you knew what you were talking about,
> rather than shoot from the hip :-)
>
>> to point you precisely where, but it seems you already know
>>that code well enough to tell where.
>
> I know perfectly well where to insert the memory barrier.

I'm not going to reply anymore to this thread, but if you don't
understand what I'm saying please stop sending stupid responses like
this one.

I'm obviously saying to patch *TAILQ* to take into account the
possibility of compiler reordering, which has nothing to do with users
knowledge of the primitive.

>
> My point is that I don't think many people amongst our users
> would realize that you _need_ memory barriers when you need
> TAILQ's and I don't think I know of a single instance in our
> source tree that does...
>
>>TAILQ is certainly subjective to aliasing because it is inlined code,
>
> It's not inlining that makes it subject to aliasing, it's the casting.
>
> Please RTFC.

What I'm saying is that there could be compiler reordering also
*among* several TAILQ operations because they are inlined functions,
not only *within* them.

Stop acting like the old teacher speaking to stupid students.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein