Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd

From: Noah Misch <noah(at)leadboat(dot)com>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd
Date: 2020-05-20 03:05:00
Message-ID: 20200520030500.GA1196868@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:
> Definition of pg_atomic_compare_exchange_u64 requires alignment of expected
> pointer on 8-byte boundary.
>
> pg_atomic_compare_exchange_u64(volatile pg_atomic_uint64 *ptr,
>                                uint64 *expected, uint64 newval)
> {
> #ifndef PG_HAVE_ATOMIC_U64_SIMULATION
>     AssertPointerAlignment(ptr, 8);
>     AssertPointerAlignment(expected, 8);
> #endif
>
>
> I wonder if there are platforms  where such restriction is actually needed.

In general, sparc Linux does SIGBUS on unaligned access. Other platforms
function but suffer performance penalties.

> And if so, looks like our ./src/test/regress/regress.c is working only
> occasionally:
>
> static void
> test_atomic_uint64(void)
> {
>     pg_atomic_uint64 var;
>     uint64        expected;
>     ...
>         if (!pg_atomic_compare_exchange_u64(&var, &expected, 1))
>
> because there is no warranty that "expected" variable will be aligned on
> stack at 8 byte boundary (at least at Win32).

src/tools/msvc sets ALIGNOF_LONG_LONG_INT=8, so it believes that win32 does
guarantee 8-byte alignment of both automatic variables. Is it wrong?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-05-20 03:08:24 Re: Parallel Seq Scan vs kernel read ahead
Previous Message Amit Kapila 2020-05-20 02:23:28 Re: Parallel Seq Scan vs kernel read ahead