gcc4 and local statics

Brian Dessent brian@dessent.net
Wed May 18 20:25:00 GMT 2005


Christopher Faylor wrote:

> Please don't cc other mailing lists along with cygwin-developers.
> 
> If you cc a subscriber-only mailing list non-subscribers will get a
> bounce when they reply.  This goes for cygwin-apps/cygwin, too.

Oh, right.  Sorry.

> Now that we know what's causing this, I guess I'd have to say that 4.
> is the way to go.  The expense of a mutex for this case doesn't seem
> worth it.

>From what I understand of this, it will affect any static objects
declared in function local scope that are given initial values/ctors. 
>From a very quick grep it seems that this is far from the only instance
of such a static -- it was just the easiest to spot since it happened to
throw a divide-by-zero exception.

It's tempting to go the -fno-threadsafe-statics route, because that
would put us back where we are currently.  I.e. gcc-3.3 did not try to
be thread-safe with these static constructors, and it seems to be an
acceptable situation at present.  So if there is a potential race
anywhere, we have been vulnerable to it forever.  In that sense, just
adding -fno-threadsafe-statics globally would be a "no worse off"
situation.  However, if there's a chance that there is actually a race
that no one has ever encountered, then implementing a mutex in the guard
functions might be a sensible thing to do in terms of long term code
hygeine.  It's possible we could lift the implementation of those guard
functions right from libstdc++, since they're conveniently added in that
patch in the gcc PR.

If we move this one instance into file scope then it seems like we'll
have to do that for all of them and that looks like it's getting ugly
fast.

Brian



More information about the Cygwin-developers mailing list