Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Because it's wrong. Removing "volatile" means that the compiler is
>> permitted to optimize away stores (and fetches!) on the basis of their
>> being unnecessary according to straight-line analysis of the code.
>> Write barriers don't fix that, they only say that stores that the
>> compiler chooses to issue at all have to be ordered a certain way.
> I don't think this is correct. The read and write barriers as
> implemented are designed to function as compiler barriers also, just
> as they do in the Linux kernel and every other piece of software I've
> found that implements anything remotely like this, with the lone
> exception of PostgreSQL. In PostgreSQL, spinlock acquisition and
> release are defined as CPU barriers but not a compiler barrier, and
> this necessitates extensive use of volatile all over the code base
> which would be unnecessary if we did this the way it's done in Linux
> and elsewhere.
I think you're just as mistaken as Zoltan. Barriers enforce ordering
of operations, not whether an operation occurs at all.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
