Re: How EGCS with multi-threaded compliance?

[ncm@cygnus.com (Nathan Myers)]

[ multithreaded static inits: ]
> >   void f()
> >   {
> >     static A a;
> >   }
> 
> > The constructor for 'a' is supposed to run the first time you enter f().
> 
> Actually, it is supposed to run the first time control passes through
> the declaration-statement, unless the object is initialized together
> with namespace-scope objects.
> 
> Since there's no requirement in the standard about making this
> thread-safe, and, in fact, the C++ Standard does not talk about
> thread-safety at all, I don't think compilers should care about this,
> since it *is* possible to perform a similiar initialization in a
> thread-safe manner:

There's no requirement for thread-safety anywhere, so why have it at all?
Because users want it.
 
> Of course, a compiler might generate this code implicitly, but I don't 
> think I would appreaciate that much hidden overhead.
 
Most of the "overhead" could be packed into a single (short) function.
The result looks vaguely like:

f()
{
  static struct { char x[sizeof A]; bool inited; } a;  
  if (!a.inited) __init_static(a.x, &_A_ctor, &a.inited);
}

The space overhead is little different from what you have now.  
Probably a single mutex would be sufficient for all the static 
locals.

In general, for thread-safety the compiler should lock for
invisible activities that are not thread-safe, so that libraries
that don't have obvious violations can easily be adopted into an
mt program.

Nathan Myers
ncm@cantrip.org