Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platforms

On 20.05.2020 08:10, Andres Freund wrote:
> Hi,
>
> On May 19, 2020 8:05:00 PM PDT, Noah Misch <noah@leadboat.com> wrote:
>> 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.
> Indeed. Cross cacheline atomics are e.g. really expensive on x86. Essentially requiring a full blown bus lock iirc.
>
Please notice that here we talk about alignment not of atomic pointer 
itself, but of pointer to the expected value.
At Intel CMPXCHG instruction read and write expected value throw AX 
register.
So alignment of pointer to expected value in 
pg_atomic_compare_exchange_u64 is not needed in this case.

And my question was whether there are some platforms where 
implementation of compare-exchange 64-bit primitive
requires stronger alignment of "expected" pointer than one enforced by 
original alignment rules for this platform.


>
> Generally the definition of the atomics should ensure the required alignment. E.g. using alignment attributes to the
struct.

Once again, we are speaking not about alignment of "pg_atomic_uint64 *ptr"
which is really enforced by alignment of pg_atomic_uint64 struct, but 
about alignment of "uint64 *expected"
which is not guaranteed.

Actually, If you allocate pg_atomic_uint64 on stack at 32-bt platform, 
then it my be also not properly aligned!
But since there is completely no sense in local atomic variables, it is 
not a problem.