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 <klep...@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
signature.asc
Description: Digital signature
