Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I think it would be useful to try to build up a library of
>> primitives in this area. For this particular task, we really
>> only need a write-with-fence primitive and a read-with-fence
>> primitive.
>
> That's really entirely the wrong way to think about it. You need
> a fence primitive, full stop. It's a sequence point, not an
> operation in itself. It guarantees that reads/writes occurring
> before or after it aren't resequenced around it. I don't even
> understand what "write with fence" means --- is the write supposed
> to be fenced against other writes before it, or other writes after
> it?
I was taking it to mean something similar to the memory guarantees
around synchronized blocks in Java. At the start of a synchronized
block you discard any cached data which you've previously read from
or written to main memory, and must read everything fresh from that
point. At the end of a synchronized block you must write any
locally written values to main memory, although you retain them in
your thread-local cache for possible re-use. Reads or writes from
outside the synchronized block can be "pulled into" the block and
reordered in among the reads and writes within the block (which may
also be reordered) unless there's another block to contain them.
It works fine once you have your head around it, and allows for
significant optimization in a heavily multi-threaded application. I
have no idea whether such a model would be useful for PostgreSQL. If
I understand Tom he is proposing what sounds roughly like what could
be achieved in the Java memory model by keeping all code for a
process within a single synchronized block, with the fence being a
point where you end it (flushing all local writes to main memory)
and start a new one (forcing a discard of locally cached data).
Of course I'm ignoring the locking aspect of synchronized blocks and
just discussing the memory access aspect of them. (A synchronized
block in Java always references some [any] Object, and causes an
exclusive lock to be held on the object from one end of the block to
the other.)
-Kevin