Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through
Date: 2005-10-13 03:49:47
Message-ID: 17248.1129175387@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Neil Conway <neilc(at)samurai(dot)com> writes:
> Another way to fix the problem would be to have S_LOCK() and S_UNLOCK()
> force $CC to not rearrange loads and stores by themselves, without
> relying upon volatile pointers.

That would certainly be better if possible, but AFAIK it's not.
(Perhaps there is a gcc-specific hack, but certainly not one that's
portable to all compilers. "volatile" is the only tool the C standard
gives us.)

Note that the S_LOCK and S_UNLOCK macros *do* incorporate commands to
prevent hardware-level reorderings, on platforms where this is
necessary. The problem at hand is basically that those optimization-
fence instructions are not visible to the compiler...

> From talking with Andrew @ Supernews on IRC, he suggested the asm
> "volatile" keyword as a possible solution ("volatile" is used for some
> platform's S_LOCK/S_UNLOCK, but not the default S_UNLOCK(), which is
> used by x86 and x86_64). [1] suggests that this keyword prevents
> rearrangement of code around the inline ASM, but the GCC docs ([2])
> don't actually state this:

Interesting point. The bug case at hand involved rearrangement of code
around an S_UNLOCK, which on x86 doesn't use any asm block, only a store
through a volatile pointer. Maybe if it had used such a block we'd not
have seen the bug. Still, I think we have to do the volatile pointers
in order to guarantee correct results on non-gcc compilers, so it's not
clear that there's any point in pursuing the question of whether gcc by
itself could offer a nicer solution.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2005-10-13 04:11:54 Re: pgsql: Do all accesses to shared buffer headers
Previous Message Neil Conway 2005-10-13 03:28:27 Re: [COMMITTERS] pgsql: Do all accesses to shared buffer

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-10-13 04:02:56 Darwin compile fixes
Previous Message Bruce Momjian 2005-10-13 03:46:31 Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking