title: Is std::string thead-safe with gcc 4.3?
body: <p>I'm developing a multithreaded program running on Linux (compiled with G++ 4.3) and if you search around for a bit you find a lot of scary stories about std::string not being thread-safe with GCC. This is supposedly due to the fact that internally it uses copy-on-write which wreaks havoc with tools like Helgrind.</p>
  
  <p>I've made a small program that copies one string to another string and if you inspect both strings they both share the same internal _M_p pointer. When one string is modified the pointer changes so the copy-on-write stuff is working fine.</p>
  
  <p>What I'm worried about though is what happens if I share a string between two threads (for instance passing it as an object in a threadsafe dataqueue between two threads). I've already tried compiling with the '-pthread' option but that does not seem to make much difference. So my question:</p>
  
  <ul>
  <li>Is there any way to force std::string to be threadsafe? I would not mind if the copy-on-write behaviour was disabled to achieve this.</li>
  <li>How have other people solved this? Or am I being paranoid?</li>
  </ul>
  
  <p>I can't seem to find a definitive answer so I hope you guys can help me..</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Wow, that's a whole lot of answers in such a short time. Thank you! I will definitely use Jack's solution when I want to disable COW. But now the main question becomes: do I really have to disable COW? Or is the 'bookkeeping' done for COW thread safe? I'm currently browsing the libstdc++ sources but that's going to take quite some time to figure out...</p>
  
  <p><strong>Edit 2</strong></p>
  
  <p>OK browsed the libstdc++ source code and I find something like this in libstd++-v3/include/bits/basic_string.h:</p>
  
  <pre><code>  _CharT*
     _M_refcopy() throw()
     {
  #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
       if (__builtin_expect(this != &amp;_S_empty_rep(), false))
  #endif
              __gnu_cxx::__atomic_add_dispatch(&amp;this-&gt;_M_refcount, 1);
       return _M_refdata();
     }  // XXX MT
  </code></pre>
  
  <p>So there is definitely something there about atomic changes to the reference counter...</p>
  
  <p><strong>Conclusion</strong></p>
  
  <p>I'm marking sellibitze's comment as answer here because I think we've reached the conclusion that this area is still unresolved for now. To circumvent the COW behaviour I'd suggest Jack Lloyd's answer. Thank you everybody for an interesting discussion!</p>