Date: Wed, 19 Nov 2014 17:11:18 +0800 From: Dennis Ferguson <dennis.c.fergu...@gmail.com>
On 19 Nov, 2014, at 01:53 , Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> 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 membar_producer elsewhere.
