On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote: > [...] > I'd also like to talk about STDCXX-1056: > > https://issues.apache.org/jira/browse/STDCXX-1056 > > which has already had an initial discussion, and for which I have > attached a patch.
I tried, unsuccessfully, to reproduce the failure observed by Martin in 22.locale.moneypunct.mt, in both debug and optimized, wide and narrow builds on a 16x machine: $ uname -a; gcc -v 2>&1 | tail -n 1; $ /lib/libc.so.6 | head -n 1 Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux gcc version 4.5.2 (GCC) GNU C Library stable release version 2.13, by Roland McGrath et al. The fact that at least one build fails is reason enough to suspect a genuine defect, but it should be reproducible, at least once in a while. I ran the test in a loop but to no avail. Sure it timeouts but once I increased the timeout to an appropriate value, it ran to completion every time. My recollection about how stdcxx string is implemented is a bit fuzzy but, IIRC, std::string is implemented as a handle-body with a reference counted body, where the counter is either an atomic counter or an integer variable protected by a mutex. In a shared body, if any of the handles undergo a potentially mutating operation (taking the address of the underlying string too, i.e., c_str), the body is copied (i.e., a deep copy of the string occurs). Also, multi-threaded manipulation of a string object should be safe as long as different threads operate on separate handles -- this is a detail of the implementation, I can't remember exactly why. When returning a new copy of an std::string from an accessor function, the body reference counter goes up. When the callee later modifies the content of the string (c_str calls included), a deep copy occurs, but in each thread via a different handle, which should be safe. It bothers me that we don't have a more robust test case for this change. Now, only Martin attached a failing test output, right? I could not see any other there. Thanks. Liviu
