| Doc. No.: | N1379 | 
|---|---|
| Date: | 2009-04-01 | 
| Reply to: | Clark Nelson | 
| Phone: | +1-503-712-8433 | 
| Email: | clark.nelson@intel.com | 
ATOMIC_FLAG_INITThe C++ CD contains the following statement:
A program that uses an object of type
atomic_flagwithout initializing it with the macroATOMIC_FLAG_INITis 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_flagthat is not explicitly initialized withATOMIC_FLAG_INITis 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.