Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
От | Jeff Davis |
---|---|
Тема | Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs) |
Дата | |
Msg-id | 1316735177.14517.13.camel@sussancws0025 обсуждение исходный текст |
Ответ на | Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: memory barriers (was: Yes, WaitLatch is vulnerable to
weak-memory-ordering bugs)
|
Список | 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
В списке pgsql-hackers по дате отправления: