Std::String in a Multi-Threaded Program

std::string in a multi-threaded program

Given that the standard doesn't say a word about memory models and is completely thread unaware, I'd say you can't definitely assume every implementation will be non-cow so no, you can't

Apart from that, if you know your tools, most of the implementations will use non-cow strings to allow multi-threading.

Is std::string thead-safe with gcc 4.3?

Threads are not yet part of the standard. But I don't think that any vendor can get away without making std::string thread-safe, nowadays. Note: There are different definitions of "thread-safe" and mine might differ from yours. Of course, it makes little sense to protect a container like std::vector for concurrent access by default even when you don't need it. That would go against the "don't pay for things you don't use" spirit of C++. The user should always be responsible for synchronization if he/she wants to share objects among different threads. The issue here is whether a library component uses and shares some hidden data structures that might lead to data races even if "functions are applied on different objects" from a user's perspective.

The C++0x draft (N2960) contains the section "data race avoidance" which basically says that library components may access shared data that is hidden from the user if and only if it activly avoids possible data races. It sounds like a copy-on-write implementation of std::basic_string must be as safe w.r.t. multi-threading as another implementation where internal data is never shared among different string instances.

I'm not 100% sure about whether libstdc++ takes care of it already. I think it does. To be sure, check out the documentation

Multithreaded idiomatic find first of substrings in a string using modern C++

I think the idiomatic way of doing it would be to use std::find_if. Then you don't need the atomic<bool> either.

// return iterator to found element or end()
auto find(const std::string & sentence)
{
    return std::find_if( std::execution::par
            , std::begin(m_Context)
            , std::end(m_Context)
            , [&sentence](const std::string & context_element) {
                return sentence.find(context_element) != std::string::npos;
            }
        );
}

If you really only want a bool you could use std::any_of:

bool find(const std::string & sentence)
{
    return std::any_of( std::execution::par
            , std::begin(m_Context)
            , std::end(m_Context)
            , [&sentence](const std::string & context_element) {
                return sentence.find(context_element) != std::string::npos;
            }
        );
}

You may want to consider using a std::vector instead of a std::list too. vectors provide random access iterators while lists only provide bidirectional iterators.

C++ multi-thread slower than single thread

First, you should display data in a sensible manner. As it is - it is hard to make any assessments. Like print time difference - so we can easily see how much time each task took instead of "how much time passed from the tasks' beginning".

Second, the tasks you run are mostly disk read/write and it is not quite parallelizable. So total execution time will not change by much.
As you schedule several unrelated tasks - they will all finish up at about the same time were it a single thread. However, since you run multiple threads each task will compete for resources - thus delaying each tasks' completion till most tasks are done.

About why "unrelated computation-only" is slowed down. This depends a lot on the computation you perform. Cannot say too much as it now aside from some generic could-be reasons. From the looks of it, you perform some memory manipulation. RAM memory access is restricted by memory bus and is generally slow. In single-threaded case a lot of the data could be still stored in the processor's memory cache speeding up considerably the amount of time it takes to process it. But this is just a general guess of what the reason could be. You ought to make a deeper analysis to find the bottleneck - on PCs processors memory bus should be more than sufficient for multiple threads.

---

Related Topics