__HAVE_64B_ATOMICS and alignment

[Torvald Riegel]

On Sat, 2016-11-26 at 19:49 +0100, Florian Weimer wrote:
> I'm trying to figure out what __HAVE_64B_ATOMICS means.

The intent is that it if nonzero, then the hardware supports 64b atomic
operations that are as fast as one would assume for the standard
general-purpose atomics support by the HW on this arch; they may come
with other requirements as typical for atomic operations.

So, for example, no 64b atomics on i686 even there's cmpxchg8 because
there is no support for efficient 64b atomic loads or stores.

The 64b atomic operations can make arch-specific requirements on the
data types that they operate on (eg, natural alignment).  Thus, if the
arch advertises that it has 64b atomics, then it should take care to
define data structures so that all code that may want to use 64b atomics
operates on data structures that fulfill those requirements.

This isn't too pretty, but we have no glibc-internal atomic data types
right now.  Maybe we should.  However, the primary clients of this
are(/were) in pthreads code, and so the data structures are often
defined in externally exposed headers.

> Does it imply 
> that atomics must be available for unaligned 64-bit objects  (such as a 
> pair of longs),

No.

> or only for 8-byte aligned values of type uint64_t?

Natural aligned data is what atomic operations on most archs require, I
believe.

> What happens if the architecture only mandates 4-byte alignment for 
> uint64_t?

Depending on what the atomics on the arch need, one may or may not have
to alter the alignment for the data to be used as target of atomics.

> I'm describing the background for this question.  The opaque sem_t 
> definition looks like this:
> 
> typedef union
> {
>    char __size[__SIZEOF_SEM_T];
>    long int __align;
> } sem_t;
> 
> But the __HAVE_64B_ATOMICS definition of the non-opaque version looks 
> like this:
> 
> struct new_sem
> {
>    uint64_t data;
>    int private;
>    int pad;
> };
> 
> This means that for an LP32 architecture such as i686 which could 
> conceivable provide 64-bit atomics, we might try to perform an atomic 
> operation on a potentially misaligned uint64_t value.

i686 has no 64b atomic loads or stores. 

> Could this be a problem on other architectures?

Maybe, but I can't think of any right now.  I suppose most archs align
naturally, which in turn suffices for atomic operations?