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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
barrier-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
