How EGCS with multi-threaded compliance?
Nathan Myers
ncm@cygnus.com
Mon Apr 13 20:27:00 GMT 1998
[ 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
More information about the Gcc
mailing list