incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject STDCXX-1056 [was: Re: STDCXX forks]
Date Mon, 03 Sep 2012 19:19:49 GMT

On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote:

> [...]
> I'd also like to talk about 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,
in both debug and optimized, wide and narrow builds on a 16x machine:

$ uname -a; gcc -v 2>&1 | tail -n 1; $ /lib/ | head -n 1
Linux behemoth #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

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.


View raw message