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

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

Hi,
> 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).
>   
Ok, I see. I was thinking that in fact, with the patch applied, people
not actually using locales pay essentially only an atomic increment.
Certainly we can't do better if we still want to use reference counting.
Seems a very nice improvement a anyway.
> Looked at libstdc++/40088, my thoughts are:
>   
Always take into account also the discussions in libstdc++/12658, but I
think by now you know pretty well those code paths (at variance with us,
at that time ;)
> . 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 see...
> . 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.
>   
If that wasn't obvious, it would probably use thread local storage,
which is standardized in C++0x and gcc does already make available as an
extension (which the library use a bit in the implementation internals).
I understand what you mean about the usability, however, interesting...
I have no idea if there are already around implementations of this
interpretation of the new C++0x thread-aware global locale model.
> . 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 have to give this more thought, definitely. In general, your feedback
in this area is much appreciated, thus, if in the future you happen to
test different solutions, have further ideas, just post here, to the
libstdc++ mailing list for discussion.
> 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!
>   
Good. I have been testing the patch and giving it more thought. It
really looks good and safe to me. Let's wait a couple of days for
comments from the other library maintainers. In my opinion it's enough
for now to close 40088, if users will report further performance problem
we can consider again the configure-time option, otherwise, let's give
the whole issue of C++0x global locales more thought before taking any
further action...

Thanks,
Paolo.