This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/7445: poor performance of std::locale::classic() in multi-threaded applications
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Cc: bkoz at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, shurik at sequoiap dot com
- Date: Thu, 8 Aug 2002 23:18:57 -0700
- Subject: Re: libstdc++/7445: poor performance of std::locale::classic() in multi-threaded applications
- Organization: Red Hat / San Francisco
- References: <20020808224918.23590.qmail@sources.redhat.com><200208082358.g78NwgTX004608@latour.rsch.comm.mot.com>
> OK, I'd be happy to find a performance fix that doesn't make the
> library code subtly less portable when we have a test case. A
> reference to code already in our test suite would be acceptable.
Yeah. This is kind of all hand-wavy at this point.
> Benjamin (as the "local locale" expert), is it *always* true that
> std::locale::classic() is called at least once during startup before
> control is transferred to main()? If so (and will always be so), then
> all thread-related locking could be removed IMHO. In practice, our
> implementation of the Standard C++ library (with optional threading
> support) already supposes that no thread which uses the library
> implementation may have ever been started before main() is invoked.
> If not true, then this change would make a very hard to detect
> threading bug when the assumption changes.
This is true. I would think the lock could then be removed? I'll let you
figure out what to do with current sources. Thanks for the help.
-benjamin