[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pserialize(9) vs. TAILQ
Date: Wed, 19 Nov 2014 17:11:18 +0800
From: Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
On 19 Nov, 2014, at 01:53 , Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> The one tricky detail is that after a reader has fetched the tqe_next
> pointer, it must issue a membar_consumer before dereferencing the
> pointer: otherwise there is no guarantee about the order in which the
> CPU will fetch the tqe_next pointer and its contents (which it may
> have cached).
I don't think it is correct to use a membar_consumer().
It is certainly /correct/. It may not be /necessary/ in some
architectures that provide more guarantees about load ordering than
are written in the program without membar_consumer.
Since most machines don't need any barrier here it would be extremely
inefficient to add a membar_consumer() since that would make all machines
pay for the idiosyncrasies unique to the DEC Alpha.
We could invent a membar_datadep_consumer for this case, and make it a
no-op on everything other than Alpha until another CPU designer
relaxes the memory ordering. The intent of the code is clearer with
the memory barrier, and it emphasizes the need for a paired
Main Index |
Thread Index |