<locale>: Excessive locking is slow
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 11.2k
- Forks
- 1.7k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 22
Description
Hello,
I’m trying migrate server application from outdated STLPort to MSSTL and faced with significant performance degradation. As it turned out, excessive locking in 'locale' library kills the performance.
Consider following code:
#include <iostream>
#include <string>
#include <sstream>
#include <locale>
struct myfacet : std::locale::facet
{
myfacet(std::size_t refs = 0) : facet(refs) { std::cout << __FUNCTION__ << std::endl; }
static std::locale::id id;
};
std::locale::id myfacet::id;
int main()
{
auto* f = new myfacet;
// point 1
std::ostringstream oss;
std::locale l = std::locale(oss.getloc(), f);
oss << 123.456 << '\n';
oss << 456.789 << '\n';
// point 2
}
Between point 1 and 2 there are 92 (sic!) _lock_locales CRT function calls. Even simple std::ostringstream creation involves 4 _lock_locales calls. This CRT function on its own turn has non-trivial behavior which only increases chances of contention on critical section which protect locales.
C++ standard defines std::locale as an immutable indexed set of immutable facets. According to definition and Technical Report on C++ Performance one may expect that creation or modification of locale object doesn’t involve locking and only atomic operation are involved. Actually, this is a case for STLPort implementation which doesn’t have any locking whatsoever.
I’ve created a simple test application which creates std::ostringstream object and add some doubles boost::posix_time::ptime (uses custom facet) objects. Below you can see latency distribution for different number of threads for MSSTL and STLPort implementation.
8 logical CPU, 4-cores:

Things becomes even worse on server grade hardware.
32 logical CPU, 16 cores:

Profiler clearly shows that significant time is spent on locks.

Unfortunately, such behavior make std::streams unusable for multithreaded server applications. Are there any chances that those locks will be removed in next releases of MSSTL and Visual Studio?
Thank you
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the provided C++ sample application and reproduce the reported _lock_locales calls while profiling threaded std::ostringstream and custom-facet use. Compare the behavior across the reported workloads and inspect the locale and stream implementation paths reached by the sample. Done means establishing whether the locking can be reduced without violating the stated locale and thread-safety requirements, with measurements showing the result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100