Re: threadsafeness at egcs1.0.3 and 1.1

[Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> > > int f()
> > > {
> > >   static int i = get_some_value();
> > >   return i;
> > > }
> 
[one thread initialising, and the other one entering]
> 
> No, this is defined in C++ as i having the value zero on the second
> call until someone starts changing i.  The implementation is required
> to not block, pend or busy wait.

No, this is undefined:

>> If control re­enters the declaration (recursively) while the object
>> is being initialized, the behavior is undefined.

Even though it says "(recursively)", I'd read that as 'access is
undefined while initialization is in progress'. So blocking in a MT
context seems acceptable.

Furthermore, the second thread must not also perform the
initialization, because i is initialized "before its block is first
entered".

Also, just skipping initialization (and thus accessing the
zero-initialized state) is not in the spirit of the spec. If
initialization is not complete, "it will be tried again the next time
control enters the declaration". Formally, this applies only to
initializations left through exceptions, but providing this semantics
in the MT case seems like a reasonable extension.

In short, g++ currently doesn't comply with the standard (no
exception-awareness), so this needs to be changed, anyway.
Considering MT here seems seems like a good idea to me, at
least as an option.

Regards,
Martin