Re: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
От
Robert Haas
Тема
Re: Re: memory barriers (was: Yes, WaitLatch is vulnerable
to weak-memory-ordering bugs)
Дата
Msg-id
CA+TgmoZYiA70M+efY785_j-camFi+NY7cSNWcoNY09JJpoqRNA@mail.gmail.com
Ответ на
Re: Re: memory barriers (was: Yes, WaitLatch is
vulnerable to weak-memory-ordering bugs) (Martijn van Oosterhout)
Список
Дерево обсуждения
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) Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
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) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
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) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
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) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
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) Gurjeet Singh <singh.gurjeet@gmail.com>
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) Peter Geoghegan <peter@2ndquadrant.com>
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) Alvaro Herrera <alvherre@commandprompt.com>
Re: memory barriers (was: Yes, WaitLatch is
vulnerable to weak-memory-ordering bugs) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: memory barriers (was: Yes, WaitLatch is vulnerable to
weak-memory-ordering bugs) Thom Brown <thom@linux.com>
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) Jeff Davis <pgsql@j-davis.com>
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) Jeff Davis <pgsql@j-davis.com>
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) Greg Stark <stark@mit.edu>
Re: Re: memory barriers (was: Yes, WaitLatch is
vulnerable to weak-memory-ordering bugs) Martijn van Oosterhout <kleptog@svana.org>
Re: Re: memory barriers (was: Yes, WaitLatch is vulnerable
to weak-memory-ordering bugs) Robert Haas <robertmhaas@gmail.com>
Re: Re: memory barriers (was: Yes, WaitLatch is
vulnerable to weak-memory-ordering bugs) Martijn van Oosterhout <kleptog@svana.org>
Re: memory barriers (was: Yes, WaitLatch is vulnerable to
weak-memory-ordering bugs) Robert Haas <robertmhaas@gmail.com>
On Sat, Sep 24, 2011 at 9:45 AM, Martijn van Oosterhout wrote: > I think memory accesses are also fantastically expensive, so it's worth > some effort to optimise that. This is definitely true. > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления