On 22 September 2011 16:18, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan <pe...@2ndquadrant.com> > wrote: >> As I've already pointed out, the comment "Won't work on Visual Studio >> 2003" is not accurate: >> >> http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.71).aspx >> >> Besides, if it's not supported, why bother mentioning it? > > I mentioned it because it took me a long time to figure out whether it > was supported or not, and I finally came to the conclusion that it > wasn't. I stand corrected, though; I've now removed that reference. > Sorry for not jumping on it sooner; it was still vaguely on my list of > things to fix at some point, but it hadn't percolated to the top yet. > > The attached version (hopefully) fixes various other things people > have complained about as well, including: > > - Heikki's complaint about sometimes writing atomic instead of barrier > (which was leftovers), and > - Gurjeet's complaint that I hadn't defined the variable anywhere > > I've also added a lengthy README file to the patch that attempts to > explain how barriers should be used in PostgreSQL coding. It's > certainly not a comprehensive treatment of the topic, but hopefully > it's enough to get people oriented. I've attempted to tailor it a bit > to PostgreSQL conventions, like talking about shared memory vs. > backend-private memory instead of assuming (as a number of other > discussions of this topic do) a thread model. It also includes some > advice about when memory barriers shouldn't be used or won't work, and > some references for further reading.
s/visca-versa/vice-versa/ s/laods/loads/ -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
