Re: testing HS/SR - 1 vs 2 performance - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: testing HS/SR - 1 vs 2 performance
Date
Msg-id r2we51f66da1004231122zc9789db6td117e913ea72ca76@mail.gmail.com
Whole thread Raw
In response to Re: testing HS/SR - 1 vs 2 performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/23/10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.com> writes:
>  > Um, you have been burned by exactly this on x86 also:
>  >   http://archives.postgresql.org/pgsql-hackers/2009-03/msg01265.php
>
>
>  Yeah, we never did figure out exactly how come you were observing that
>  failure on Intel-ish hardware.  I was under the impression that Intel
>  machines didn't have weak-memory-ordering behavior.
>
>  I wonder whether your compiler had rearranged the code in ProcArrayAdd
>  so that the increment happened before the array element store at the
>  machine-code level.  I think it would be entitled to do that under
>  standard C semantics, since that ProcArrayStruct pointer isn't marked
>  volatile.

Sounds likely.

Which seems to hint its better to handle all processors as weak ordered
and then work with explicit locks/memory barriers, than to sprinkle
code with 'volatile' to supress optimizations on intel and then still
fail on non-intel.

-- 
marko


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Next
From: Tom Lane
Date:
Subject: Re: psql: Add setting to make '+' on \d implicit