Note that there are some explanatory texts on larger screens.

plurals
  1. POstd::string in a multi-threaded program
    text
    copied!<p>Given that:</p> <p>1) The C++03 standard does not address the existence of threads in any way</p> <p>2) The C++03 standard leaves it up to implementations to decide whether <code>std::string</code> should use Copy-on-Write semantics in its copy-constructor</p> <p>3) Copy-on-Write semantics often lead to unpredictable behavior in a multi-threaded program</p> <p>I come to the following, seemingly controversial, conclusion:</p> <p><strong>You simply cannot safely and portably use std::string in a multi-threaded program</strong></p> <p>Obviously, no STL data structure is thread-safe. But at least, with std::vector for example, you can simply use mutexes to protect access to the vector. With an std::string implementation that uses COW, you can't even reliably do that without editing the reference counting semantics deep within the vendor implementation.</p> <p>Real-world example:</p> <p>In my company, we have a multi-threaded application which has been thoroughly unit-tested and run through Valgrind countless times. The application ran for months with no problems whatsoever. One day, I recompile the application on another version of gcc, and all of a sudden I get random segfaults all the time. Valgrind is now reporting invalid memory accesses deep within libstdc++, in the std::string copy constructor.</p> <p>So what is the solution? Well, of course, I could typedef <code>std::vector&lt;char&gt;</code> as a string class - but really, that sucks. I could also wait for C++0x, which I pray will require implementors to forgo COW. Or, (shudder), I could use a custom string class. I personally always rail against developers who implement their own classes when a preexisting library will do fine, but honestly, I need a string class which I can be sure is not using COW semantics; and std::string simply doesn't guarantee that. </p> <p>Am I right that <code>std::string</code> simply cannot be used reliably <em>at all</em> in portable, multi-threaded programs? And what is a good workaround?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload