Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd
От | Noah Misch |
---|---|
Тема | Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd |
Дата | |
Msg-id | 20200520030500.GA1196868@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd
Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platforms |
Список | 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?
В списке pgsql-hackers по дате отправления: