This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc4 and local statics


On Wed, May 18, 2005 at 01:26:15PM -0700, Brian Dessent wrote:
>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.

I know that whenever I use a static like this, I always think that they
will be initialized similar to the way C initialized them which, AFAIK,
is at program load time rather than when the function is visited.  So,
I suspect that some of the code that I've written has an implicit assumption
which is wrong.

It seems like static is being used like this in 28 different cases.  It
shouldn't be a big problem to audit the usage here and see if we really
need a gcc4-only option, with all of the headaches that will introduce
to the Makefile.

In the case of granularity, I think I'd actually opt for just making it
an automatic variable rather than a static variable.  There doesn't seem
to be any reason to ever initialize granularity unless mmap64 is used,
and the call is pretty cheap.  I'm not even sure how granularity is
supposed to be initialized when it is being set to the value of a
function.  Is it only supposed to call the function once and once-only?
If so, that would imply logic to avoid calling getshmlba more than once
which almost negates the overhead of just calling getshmlba every time.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]