Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Date: Sun, 5 Feb 2012 03:14:58 +0000 (UTC)
From: "Martin Sebor (Commented) (JIRA)" <jira@apache.org>
To: issues@stdcxx.apache.org
Message-ID: 
 <68733673.12415.1328411698782.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1798540128.12171.1328401554492.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct
 implementations are not thread-safe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200645#comment-13200645 ] 

Martin Sebor commented on STDCXX-1056:
--------------------------------------

What you describe sounds like a bug in the implementation of std::string (it could also be a bug in the thread safety of the facets) which is supposed to be thread safe. We have pretty thorough tests for the thread safety of the string classes but it's certainly possible that there's a bug. I suspect the thread safety tests for facets are much weaker.

FYI: the plan for stdcxx 5.0 has been to change the default configuration of basic_string to not be reference counted for efficiency on SMP systems. We can't make this change in 4.x because of binary compatibility, although I think there's a macro that lets you control it if you don't care about binary compatibility.

If there's a bug in the thread safety of the facet classes (which is quite possible, especially with their lazy initialization), we should be able to fix it without breaking compatibility.
                
> 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
>
>
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira