Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> there are three questions that you might want to answer here:
>
> 1. I have a new architecture and I want barrier.h to support it.
> What do I need to do?
> 2. What is the behavior of the various constructs provided by
> barrier.h?
> 3. Why would I want that behavior and how can I use it to do cool
> stuff?
>
> I intended the comment in that file to be enough to answer
> questions #1 and #2. What you and Heikki are asking about is
> really #3, and that seems to me to be setting the bar awfully
> high.
OK, put that way, I mostly agree. A general overview of the known
usage patterns in a header or README file still doesn't seem out of
line to me. With LW locks, for example, I've only seen two patterns
used in PostgreSQL:
(1) Get a shared lock for reads and an exclusive lock for writes, or
(2) get a shared lock to read or write your own data, but an
exclusive lock to read anyone else's data.
In both cases, there must be a defined order of lock acquisition to
avoid deadlock, with a strong recommendation that locks be released
in the reverse order. Mentioning that much doesn't preclude other
uses of LW locks, but might help people new to the code. That's the
level of summary *I* would like to see included.
> What I found hard about memory barriers is basically this: I
> didn't understand that the CPU is allowed to perform operations
> out of order. And I couldn't understand what the consequences of
> that fact were. I sort of understood - but hadn't really
> internalized - the idea that execution is highly pipelined, so the
> single moment at which an execution is performed is not well
> defined. Before I really got my head around it, I had to read the
> explanations of what a memory barrier actually does over and over
> again. I probably read ten different explanations saying the same
> thing in different words about twenty times a piece, and slowly
> the light dawned. I did my best to explain that in the existing
> comment; I'm happy to expand the comment if people have
> suggestions for what to put in there; but basically I think this
> is a hard concept and if you haven't done this stuff before it's
> going to take a while to get up to speed.
That's the sort of thing where it would be helpful to provide one or
two URLs for cogent explanations of this. Even if it takes repeated
readings and meditations on the explanations for it to sink in, this
is worth it. (For SSI I had to read the paper many times, and then
go read several referenced papers, before I really had my head
around it, and I've had others say the same thing. But having a
link to the material gives someone a chance to *do* that.)
-Kevin