__HAVE_64B_ATOMICS and alignment

__HAVE_64B_ATOMICS and alignment

[Florian Weimer]

I'm trying to figure out what __HAVE_64B_ATOMICS means.  Does it imply 
that atomics must be available for unaligned 64-bit objects  (such as a 
pair of longs), or only for 8-byte aligned values of type uint64_t? 
What happens if the architecture only mandates 4-byte alignment for 
uint64_t?

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.

Could this be a problem on other architectures?  (IA-32 is generally 
fine with atomic operations on unaligned objects.)

Thanks,
Florian

Re: __HAVE_64B_ATOMICS and alignment

[Andreas Schwab]

On Nov 26 2016, Florian Weimer <fweimer@redhat.com> wrote:

> 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.

It has always been true that sem_t must have the same or higher
alignment as struct new_sem.

> Could this be a problem on other architectures?  (IA-32 is generally fine
> with atomic operations on unaligned objects.)

That's why AArch64 ILP32 changes sem_t to use long long.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: __HAVE_64B_ATOMICS and alignment

[Florian Weimer]

On 11/26/2016 09:52 PM, Andreas Schwab wrote:
> On Nov 26 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> 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.
>
> It has always been true that sem_t must have the same or higher
> alignment as struct new_sem.
>
>> Could this be a problem on other architectures?  (IA-32 is generally fine
>> with atomic operations on unaligned objects.)
>
> That's why AArch64 ILP32 changes sem_t to use long long.

But shouldn't this work out of the box, i.e., with the generic sem_t, 
you get something that is usable whether __HAVE_64B_ATOMICS is defined 
or not?

And it doesn't quite answer my question.

Florian

Re: __HAVE_64B_ATOMICS and alignment

[Andreas Schwab]

On Nov 27 2016, Florian Weimer <fweimer@redhat.com> wrote:

> But shouldn't this work out of the box, i.e., with the generic sem_t, you
> get something that is usable whether __HAVE_64B_ATOMICS is defined or not?

Alignment is inherently archtecture dependent.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: __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?

Re: __HAVE_64B_ATOMICS and alignment

[Florian Weimer]

On 11/28/2016 12:51 PM, Torvald Riegel wrote:
>> 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.

double loads and stores via the FPU are atomic, and they preserve all 
bit patterns.  (Starting with the Pentium, the FPU was sometimes used to 
implement string copies.)  Hotspot uses this capability to implement 
volatile doubles and longs if SSE is not available, so it better be true. :)

Thanks,
Florian

Re: __HAVE_64B_ATOMICS and alignment

[Torvald Riegel]

On Thu, 2017-04-13 at 07:10 +0200, Florian Weimer wrote:
> On 11/28/2016 12:51 PM, Torvald Riegel wrote:
> >> 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.
> 
> double loads and stores via the FPU are atomic, and they preserve all 
> bit patterns.

I believe that the precise status on this is that we believe that they
are atomic, but it's not explicitly guaranteed.

Either way, glibc does not provide 64b atomics on i686.  If we would
change that, we would have to review data structure declarations,
including alignment, of data that could be the target of such 64b
atomics.

Re: __HAVE_64B_ATOMICS and alignment

[Richard Henderson]

On 04/13/2017 10:16 AM, Torvald Riegel wrote:
> On Thu, 2017-04-13 at 07:10 +0200, Florian Weimer wrote:
>> On 11/28/2016 12:51 PM, Torvald Riegel wrote:
>>>> 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.
>>
>> double loads and stores via the FPU are atomic, and they preserve all
>> bit patterns.
>
> I believe that the precise status on this is that we believe that they
> are atomic, but it's not explicitly guaranteed.

No, it is guaranteed.  See Vol 3, Section 8.1.1:

# The Pentium processor (and newer processors since) guarantees that
# the following additional memory operations will always be carried
# out atomically:
# • Reading or writing a quadword aligned on a 64-bit boundary


r~

Re: __HAVE_64B_ATOMICS and alignment

[Joseph Myers]

On Thu, 13 Apr 2017, Florian Weimer wrote:

> On 11/28/2016 12:51 PM, Torvald Riegel wrote:
> > > 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.
> 
> double loads and stores via the FPU are atomic, and they preserve all bit
> patterns.  (Starting with the Pentium, the FPU was sometimes used to implement

Note that only works for *integer* loads and stores (fild / fistp).  You 
can't use float or double loads and stores for arbitrary bit patterns 
because if the bit patterns look like signaling NaNs, they'll be converted 
to (long double) qNaNs, the "invalid" exception will be raised and the bit 
pattern will not be preserved when the valid is stored back from the FPU.

-- 
Joseph S. Myers
joseph@codesourcery.com