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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Date: 2011-09-15 15:57:56
Message-ID: 4E722084.4000202@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.09.2011 23:29, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas<robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-09-15 16:44:20 Patch: Perl xsubpp
Previous Message Yeb Havinga 2011-09-15 15:30:56 Re: Patch for cursor calling with named parameters