Re: Latches with weak memory ordering (Re: max_wal_senders must die)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Date: 2010-11-19 15:36:06
Message-ID: 29758.1290180966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... The reason memory
> barriers solve the problem is because they'll be atomically released
> when we jump into the signal handler, but that is not true of a
> spin-lock or a semaphore.

Hm, I wonder whether your concern is stemming from a wrong mental
model. There is nothing to "release". In my view, a memory barrier
primitive is a sequence point, having the properties that all writes
issued before the barrier shall become visible to other processors
before any writes after it, and also that no reads issued after the
barrier shall be executed until those writes have become visible.
(PPC can separate those two aspects, but I think we probably don't
need to get that detailed for our purposes.) On most processors,
the barrier primitive will just be ((void) 0) because they don't
deal in out-of-order writes anyway.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaibhav Kaushal 2010-11-19 15:41:09 What do these terms mean in the SOURCE CODE?
Previous Message Tom Lane 2010-11-19 15:25:13 Re: libpq changes for synchronous replication