Re: Latches with weak memory ordering (Re: max_wal_senders must die) - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Date
Msg-id AANLkTikjwMonzTY_6qufx9bNuKDZXmJo6o2nXnqDAzZ4@mail.gmail.com
Whole thread Raw
In response to Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Andres Freund <andres@anarazel.de>)
Responses Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Re: Latches with weak memory ordering (Re: max_wal_senders must die)
List pgsql-hackers
On Fri, Nov 19, 2010 at 9:49 AM, Andres Freund <andres@anarazel.de> wrote:
> Well, its not generally true - you are right there. But there is a wide range
> for syscalls available where its inherently true (which is what I sloppily
> referred to). And you are allowed to call a, although quite restricted, set of
> system calls even in signal handlers. I don't have the list for older posix
> versions in mind, but for 2003 you can choose something from several like
> write, lseek,setpgid which inherently have to serialize. And I am quite sure
> there were sensible calls for earlier versions.

Well, it's not quite enough just to call into the kernel to serialize
on "some point of memory", because your point is to make sure that
*this particular piece of memory* is coherent.  It doesn't matter if
the kernel has proper fencing in it's stuff if the memory it's
guarding is in another cacheline, because that won't *necessarily*
force cache coherency in your local lock/variable memory.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.


pgsql-hackers by date:

Previous
From: Shigeru HANADA
Date:
Subject: Re: SQL/MED estimated time of arrival?
Next
From: Tom Lane
Date:
Subject: Re: Latches with weak memory ordering (Re: max_wal_senders must die)