[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461452#comment-13461452
]
Liviu Nicoara commented on STDCXX-1056:
---------------------------------------
This summarizes the findings that occurred during the long (!) discussion on
the mailing list:
1. Data caching in the facet object, and the access to it, was improperly
guarded
2. Concurrent modification of the same string member (via same handle) occurs
3. Stefan identified race conditions in the locale/facet code, beyond caching
4. Stefan provided a clean, race-free patch (although its scope is contested)
5. Alternatively, the simple elimination of locale data caching eliminates test
suite failures
Besides the obvious defect in caching, DCII occurs in the facet initialization
code which would make it thread unsafe although we don't currently have a
failing test case.
The patch from Stefan eliminates all race conditions and effectively
synchronizes all access to facet data. Performance data is not available. It is
very possible that this strict synchronization matters very little in the
overall picture of the localization library performance.
Alternatively, the simplest and least invasive solution at the moment is to
just eliminate the caching code. This keeps the fast, unguarded reads of the
facet data and relies on the (disputed) thread-safety of the facet
initialization code. Timings showed better performance on SMP than the cached
facet, and way worse in ST. It also plays in future development with a
non-reference counted std::string.
The DCII is a serious matter even though there is no failing test case yet. A
memory barrier API, recognized by the compiler, would allow us to preserve the
fast, unguarded reads of facet data (and even caching).
> std::moneypunct and std::numpunct implementations are not thread-safe
> ---------------------------------------------------------------------
>
> Key: STDCXX-1056
> URL: https://issues.apache.org/jira/browse/STDCXX-1056
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
> Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++
> Compilers 12.1, 12.2, 12.3
> Issue is independent of platform and/or compiler.
> Reporter: Stefan Teleman
> Labels: thread-safety
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out,
> runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz,
> stdcxx-1056.patch, stdcxx-1056-timings.tgz,
> stdcxx-4.2.x-numpunct-perfect-forwarding.patch,
> stdcxx-4.3.x-numpunct-perfect-forwarding.patch
>
>
> several member functions in std::moneypunct<> and std::numpunct<> return
> a std::string by value (as required by the Standard). The implication of
> return-by-value
> being that the caller "owns" the returned object.
> In the stdcxx implementation, the std::basic_string copy constructor uses a
> shared
> underlying buffer implementation. This shared buffer creates the first
> problem for
> these classes: although the std::string object returned by value *appears* to
> be owned
> by the caller, it is, in fact, not.
> In a mult-threaded environment, this underlying shared buffer can be
> subsequently modified by a different thread than the one who made the initial
> call. Furthermore, two or more different threads can access the same shared
> buffer at the same time, and modify it, resulting in undefined run-time
> behavior.
> The cure for this defect has two parts:
> 1. the member functions in question must truly return a copy by avoiding a
> call to the copy constructor, and using a constructor which creates a deep
> copy of the std::string.
> 2. access to these member functions must be serialized, in order to guarantee
> atomicity
> of the creation of the std::string being returned by value.
> Patch for 4.2.1 to follow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
