On Sat, Sep 24, 2011 at 12:46:48PM -0400, Robert Haas wrote:
> > I found the Linux kernel document on this topic quite readable. I think
> > the main lesson here is that processors track data dependancies (other
> > than the Alpha apparently), but not control dependancies. So in the
> > example, the value of i is dependant on num_items, but not via any
> > calculation. IThat control dependancies are not tracked makes some
> > sense, since branches depend on flags bit, and just about any
> > calculation changes the flag bits, but most of the time these changes
> > are not used.
>
> Oh, that's interesting. So that implies that a read-barrier would be
> needed here even on non-Alpha.
That is my understanding. At source code level the address being
referenced is dependant on i, but at assembly level it's possible i has
been optimised away altogether.
I think the relevent example is here:
http://www.mjmwired.net/kernel/Documentation/memory-barriers.txt (line 725)
Where A = q->items[0] and B = q->num_items.
There is no data dependancy here, so inserting such a barrier won't
help. You need a normal read barrier.
OTOH, if the list already has an entry in it, the problem (probably)
goes away, although with loop unrolling you can't really be sure.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts. -- Arthur Schopenhauer
