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

[Jimmy Guo <jguo at yahoo-inc dot com>]

> 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?

Thanks I'm glad this is an issue on your radar screen :)  We are actually
stuck at an older gcc version and upgrading gcc is currently out-of-plan, so
my patch may be the only option available to me (short of commenting out
locks and making locale::global() a nop).  In that regard, I consider the
performance gain acceptable for lack of other options.  With this patch, the
real app in question actually delivered 25% lower latency (aggregate over a
clustered environment, measured from master nodes doing fan-out / fan-in).

Looked at libstdc++/40088, my thoughts are:

. A configure-time option is probably the cheapest way to get more
performance improvement, and it would definitely benefit installations that
can re-build and use a custom version of gcc.  Since this is a performance
issue, those who care would know what they are doing :)  For me,
unfortunately we share our custom gcc build with other projects that pulling
the plug on proper global locale support may be out of the question.

. I'm not sure how a per-thread global cache would work out ... haven't
given it much thought.  If it means each thread could have different global
locales (i.e. no sync among these caches), it may be a usability issue,
although performance would be good.

. Originally I was thinking maybe a global objects sink can be implemented
to avoid the case where global locale objects could be destroyed ... this is
the main reason we need mutex protection (sans per-thread global cache).
The idea being even apps using locale::global() would not do a lot of
_global_ locale switching during runtime (or they would fair better with
setlocale() to individual usecases).  In this case by pushing these (once)
global locale objects into a sink, they will never be destroyed.  But
probably that's a gross hack :)

>> 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.

Look forward to more scrutiny, but thanks for your initial thoughts on the
patch ... such assurances are very encouraging for me to push for this patch
within my organization!

- Jimmy Guo