On 14.09.2011 23:29, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas<robertmhaas@gmail.com> wrote:
>> I've been thinking about this too and actually went so far as to do
>> some research and put together something that I hope covers most of
>> the interesting cases. The attached patch is pretty much entirely
>> untested, but reflects my present belief about how things ought to
>> work.
>
> And, here's an updated version, with some of the more obviously broken
> things fixed.
s/atomic/barrier/
> +/*
> + * A compiler barrier need not (and preferably should not) emit any actual
> + * machine code, but must act as an optimization fence: the compiler must not
> + * reorder loads or stores to main memory around the barrier. However, the
> + * CPU may still reorder loads or stores at runtime, if the architecture's
> + * memory model permits this.
> + *
> + * A memory barrier must act as a compiler barrier, and in addition must
> + * guarantee that all loads and stores issued prior to the barrier are
> + * completed before any loads or stores issued after the barrier. Unless
> + * loads and stores are totally ordered (which is not the case on most
> + * architectures) this requires issuing some sort of memory fencing
> + * instruction.
This seems like a strange way to explain the problem. I would suggest
structuring those paragraphs along the lines of:
"
A PostgreSQL memory barrier guarantees that any loads/stores before the
barrier are completely finished and visible to other CPUs, before the
loads/stores after the barrier are performed.
That involves two things: 1. We must stop the compiler from rearranging
loads/stores across the barrier. 2. We must stop the CPU from reordering
the loads/stores across the barrier.
"
Do we have any use for compiler barriers that are not also memory
barriers? If not, I would suggest not exposing the pg_compiler_barrier()
macro, but keep that as an implementation detail in the implementations
of pg_memory_barrier().
Some examples on the correct usage of these barriers would be nice, too.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com