Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)

On 22 September 2011 16:18, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)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