Date: Wed, 10 Feb 2021 18:51:15 +0000
On Wed, 10 Feb 2021, Uecker, Martin via Liaison wrote:
> > Whatever system you might add for atomic operations on non-atomic data, I
> > think making the syntactic-qualifier _Atomic into something semantically a
> > qualifier would be an unreasonably incompatible way of adding such a
> > feature.
>
> A qualifier is exactly what is needed if you want to
> express atomic operations on non-atomic data as it has
> exactly the right right semantics. Qualifiers affect
You need the various *operations* from stdatomic.h in forms that can be
applied to non-atomic data. Whether you need to be able to use the cases
of direct assignment implying seq_cst for atomic accesses to non-atomic
data, or just the operations in stdatomic.h, seems less clear to me.
(I realise that some things that can be done with direct assignment
operators have no corresponding stdatomic.h operations; for example,
atomic compound assignment for floating-point types with all the
corresponding implications for handling floating-point exception state.
However, such operations could be added to stdatomic.h, so allowing an
explicit memory order to be specified, independent of any way to apply
atomic operations to non-atomic data.)
> If the problem is only alignment, then I think this could
> be made backwards compatible (as pointed out in my
> other email).
Alignment differences imply size differences once you include the atomic
object into a larger struct. (And I think some implementations may e.g.
enlarge _Atomic struct { char x[3]; } to 4 bytes, adding padding in order
to increase its alignment.)
> > Whatever system you might add for atomic operations on non-atomic data, I
> > think making the syntactic-qualifier _Atomic into something semantically a
> > qualifier would be an unreasonably incompatible way of adding such a
> > feature.
>
> A qualifier is exactly what is needed if you want to
> express atomic operations on non-atomic data as it has
> exactly the right right semantics. Qualifiers affect
You need the various *operations* from stdatomic.h in forms that can be
applied to non-atomic data. Whether you need to be able to use the cases
of direct assignment implying seq_cst for atomic accesses to non-atomic
data, or just the operations in stdatomic.h, seems less clear to me.
(I realise that some things that can be done with direct assignment
operators have no corresponding stdatomic.h operations; for example,
atomic compound assignment for floating-point types with all the
corresponding implications for handling floating-point exception state.
However, such operations could be added to stdatomic.h, so allowing an
explicit memory order to be specified, independent of any way to apply
atomic operations to non-atomic data.)
> If the problem is only alignment, then I think this could
> be made backwards compatible (as pointed out in my
> other email).
Alignment differences imply size differences once you include the atomic
object into a larger struct. (And I think some implementations may e.g.
enlarge _Atomic struct { char x[3]; } to 4 bytes, adding padding in order
to increase its alignment.)
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-02-10 12:51:23