64-bit atomic ops on 32-bit ARM

64-bit atomic ops on 32-bit ARM

[Matthew Fernandez]

Hi all,

The header atomic.h contains a couple of functions for operations on 64-bit types. Despite their
name, these do not appear to be atomic to me. For example:

  static inline void a_and_64(volatile uint64_t *p, uint64_t v)
  {
    union { uint64_t v; uint32_t r[2]; } u = { v };
    a_and((int *)p, u.r[0]);
    a_and((int *)p+1, u.r[1]);
  }

Have I misunderstood something or is there some other reason behind their implementation? AIUI on
certain ARM platforms there is actually no way to implement atomic 64-bit ops without kernel support.

If replying, please CC me directly as I'm not on the list.

Thanks,
Matt

________________________________

The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

Re: 64-bit atomic ops on 32-bit ARM

[Rich Felker]

On Thu, Feb 06, 2014 at 09:56:47AM +1100, Matthew Fernandez wrote:
> Hi all,
> 
> The header atomic.h contains a couple of functions for operations on 64-bit types. Despite their
> name, these do not appear to be atomic to me. For example:
> 
>  static inline void a_and_64(volatile uint64_t *p, uint64_t v)

The function name is simply a misnomer. It should be called "atomic
bitclear" (and, for "or", "atomic bitset). That's the only way it's
actually used. In other words we don't care that the and/or operation
on both words happen atomically with respect to one another, only that
each bit individually behaves atomically with respect to being set and
cleared.

BTW, changing the name and semantics would also allow us to drop from
performing two atomic operations to just performing on atomic
operation (on the word that actually needs to change). This would be a
fairly significant optimization, I think. But for now it's not a bug,
just a missed optimization.

Rich

Re: 64-bit atomic ops on 32-bit ARM

[Matthew Fernandez]

Ah, so it's used for operating on 64-bit bitfields. Presumably the meaning of each bit is orthogonal
to the others so the atomicity of the write as a whole is irrelevant. Thanks for the clarification,
Rich.

On 06/02/14 10:06, Rich Felker wrote:
> On Thu, Feb 06, 2014 at 09:56:47AM +1100, Matthew Fernandez wrote:
>> Hi all,
>>
>> The header atomic.h contains a couple of functions for operations on 64-bit types. Despite their
>> name, these do not appear to be atomic to me. For example:
>>
>>   static inline void a_and_64(volatile uint64_t *p, uint64_t v)
>
> The function name is simply a misnomer. It should be called "atomic
> bitclear" (and, for "or", "atomic bitset). That's the only way it's
> actually used. In other words we don't care that the and/or operation
> on both words happen atomically with respect to one another, only that
> each bit individually behaves atomically with respect to being set and
> cleared.
>
> BTW, changing the name and semantics would also allow us to drop from
> performing two atomic operations to just performing on atomic
> operation (on the word that actually needs to change). This would be a
> fairly significant optimization, I think. But for now it's not a bug,
> just a missed optimization.
>
> Rich
>

________________________________

The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.