Doc. No.: | N1379 |
---|---|
Date: | 2009-04-01 |
Reply to: | Clark Nelson |
Phone: | +1-503-712-8433 |
Email: | clark.nelson@intel.com |
ATOMIC_FLAG_INIT
The C++ CD contains the following statement:
A program that uses an object of type
atomic_flag
without initializing it with the macroATOMIC_FLAG_INIT
is ill-formed.
A type for which explicit initialization is necessary is not unprecedented for C++; reference types and class types with an explicitly-declared constructor but no default constructor are examples. However, a requirement like this would be unprecedented for C, which has no kind of type for which explicit initialization is required.
The rationale for the requirement of ATOMIC_FLAG_INIT
is that,
even though effectively all architectures usable in multi-processor systems have
instructions suitable for implementing atomic_flag
operations,
there are some for which a zero-valued object would correspond to a flag in the
set state, rather than a flag in the reset state. So a zero-initialized
atomic_flag
object will be in a different initial state on different
architectures. However, this is not a fatal condition, since it still possible
to initialize an atomic_flag
by using atomic_flag_reset
.
Therefore, it is more appropriate for the C standard simply to state the reality implied by the variety of existing hardware:
An
atomic_flag
that is not explicitly initialized withATOMIC_FLAG_INIT
is initially in an indeterminate state.
For the sake of compatibility between C and C++, WG21 should consider making the same change to the C++ standard.