Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thom Brown <thom@linux.com>, Peter Geoghegan <peter@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2011-09-22T23:46:17Z
Lists: pgsql-hackers
On Thu, 2011-09-22 at 19:12 -0400, Robert Haas wrote: > But since you asked... as I > understand it, unless you're running on Alpha, you actually don't need > a barrier here at all, because all currently-used CPUs other than > alpha "respect data dependencies", which means that if q->num_items is > used to compute an address to be read from memory, the CPU will ensure > that the read of that address is performed after the read of the value > used to compute the address. At least that's my understanding. But > Alpha won't. I'm still trying to figure out how it's even possible to read an address that's not computed yet. Something sounds strange about that... I think it might have more to do with branch prediction or something else. In your example, the address is not computed from q->num_items directly, it's computed using "i". But that branch being followed is dependent on a comparison with q->num_items. Maybe that's the dependency that's not respected? Regards, Jeff Davis