Re: Reduce libstdc++-v3 locale::locale() lock contention

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> Hi this is a patch to libstdc++-v3 to reduce locale::locale() lock
> contention for applications that only use C locale.  Through lock contention
> analysis we found that one of our apps has high contention involving
> istringstream and the underlying ios_base locale() construction.  Since we
> don't change our default / global locale, one solution is to apply this
> patch to our gcc.  Would like your review of this patch, which I think is
> still applicable to gcc trunk.
>   
First, thanks for your help on this issue, which actually is also
libstdc++/40088 in our Bugzilla: I would like to ask you to have a look
to it in its entirety, to have a more complete perspective. Talking
about the audit trail of that bug, I'm still of the opinion that maybe
it would make sense to provide also a configure-time option to disable
the locking completely, if the user knows what he's doing (then
eventually for C++0x have a per-thread global locale): what do you think
about that? Do you think that with your patch applied the performance
are good enough in the vast majority of applications?
> Some timing data on my 8 core (Core2Quad) node running RHEL4:
>
> Using current libstdc++.so:
> nthreads = 1: 1725 cycles
> nthreads = 2: 6968 cycles
> nthreads = 4: 27381 cycles
> nthreads = 8: 36594 cycles
>
> Using patched libstdc++.so:
> nthreads = 1: 1392 cycles
> nthreads = 2: 2746 cycles
> nthreads = 4: 7854 cycles
> nthreads = 8: 21114 cycles
>
> Test code for the above basically measures clock cycles (rdtsc) around
> thread func that does the following:
>     for (int i = 0; i < NITERS; ++i) {
>         std::ostringstream bufStream;
>         bufStream << i;
>     }
>
> In the locale::locale() constructor, the patch optimizes away the mutex lock
> when _S_global Impl* is still _S_classic.  If it's not, it falls back to the
> original behavior of using the mutex to protect access to _S_global and its
> reference count.  I've added some inline comments in the patch as well.
>
> I'd appreciate your review and thoughts on how to address this, if
> alternatives exist, or if you have considered this already but decided not
> to adopt similar patches ... thanks!
>   
Thanks for the patch. My first impression is that it looks very good,
and I would like to solicit the feedback of the other maintainers about
it, we could certainly apply it in time for 4.5.0.

Thanks,
Paolo.