Re: std::string & multithreading

[Radu Marginean <radu_marg at yahoo dot com>]

Indeed the problem does not occur when accessing unrelated strings. Here is a backtrace:

#0  0x00007f1621dedffb in memcpy () from /lib64/libc.so.6
#1  0x00007f162239da6c in ?? () from /usr/lib64/libstdc++.so.6
#2  0x00007f162239dc3a in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned long, unsigned long)
    () from /usr/lib64/libstdc++.so.6
#3  0x00007f162239dc72 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::substr(unsigned long, unsigned long) const ()
   from /usr/lib64/libstdc++.so.6
#4  0x000000000042bf46 in Parsers::HTMLParser::ExtractWordsAndLinks (
    this=0x7f16057f1580) at parsers/HTMLParser.cpp:352
#5  0x000000000042e3f3 in Parsers::HTMLParser::Run (this=0x7f16057f1580)
    at parsers/HTMLParser.cpp:62
#6  0x000000000040e59a in downloader_thread (arg=0x7f15e0151110)
    at src/downloader_thread.hpp:406
#7  0x00007f16225f2070 in start_thread () from /lib64/libpthread.so.0
#8  0x00007f1621e4111d in clone () from /lib64/libc.so.6

The specific code line where it fails is line 352:
> fragment = fragment.substr (0, fragment.length() - 1);
 
Is there any method to avoid this problem?

Thank you,
Radu


--- On Fri, 2/26/10, Marc Glisse <marc.glisse@normalesup.org> wrote:

> From: Marc Glisse <marc.glisse@normalesup.org>
> Subject: Re: std::string & multithreading
> To: "Radu Marginean" <radu_marg@yahoo.com>
> Cc: libstdc++@gcc.gnu.org
> Date: Friday, February 26, 2010, 6:32 AM
> On Fri, 26 Feb 2010, Radu Marginean
> wrote:
> 
> > Currently std::string cannot be safely used in a
> multithreaded environment due to features like copy on write
> and reference counting. Even programs that access two
> unrelated different string objects in a multicore machine
> may suffer random crashes.
> 
> Is that really the case? Last time I checked, the
> implementation didn't use any global/static variables, so no
> reason for unrelated strings to interact, and the reference
> counting used atomic operations, which is enough to allow
> for quite a few multithreading scenarios. Now obviously that
> doesn't make operations on strings atomic, but that is
> seldom needed.
> 
> For what precise use did you notice these random crashes?
> 
> -- Marc Glisse
>