PR 5432: Thread safety patches

[Loren James Rittle]

In article <20020119203538.A52196@cantrip.org> you write:
> A question for the group: In
>
>   static _Atomic_word top = 4; 
>
> below, is the initialization guaranteed to happen at link time,
> rather than on function entry time, on all architectures?  

Good catch Nathan.  The guarantee of ISO-C++-14882 is not as tight as
ISO-C-9899:1999.

If the value was zero instead of 4, it would be guaranteed to happen
before main() was entered.  See section 6.7 of ISO-C++-14882: "A local
object of POD type with static storage duration initialized with
constant-expression [other than zero] is initialized before its block
is first entered."

On every target I know about, g++ actually implements POD static
initialization as it would be done for C thus this text drives the
implementation-defined behavior (from section 5.1.2 of
ISO-C-9899:1999): "All objects with static storage duration shall be
initialized (set to their initial values) before program startup.  The
manner and timing of such initialization are otherwise unspecified."

To adhere to the guarantee of the standard, the code should be
restructured to zero initialize _Atomic_word and then always add 4 to
the return value.  However, ...

> Note that it may (come to) be a struct on some.  If that happens, then 
> if its constructor is declared explicit (as it should be), the above 
> will fail, which is good, because the above would not be thread-safe 
> if it involved a constructor call that would necessarily happen at 
> function entry.  Probably a comment to that effect would be advisable.

Agreed.

Regards,
Loren