多线程程序中的std :: string [英] std::string in a multi-threaded program

问题描述

考虑到：

1）C ++ 03标准没有以任何方式解决线程的存在

1) The C++03 standard does not address the existence of threads in any way

2）C ++ 03标准将其留给实现来决定 std :: string 是否应在其复制构造函数中使用写时复制语义

2) The C++03 standard leaves it up to implementations to decide whether std::string should use Copy-on-Write semantics in its copy-constructor

3）写时复制语义通常会导致多线程程序中无法预测的行为

3) Copy-on-Write semantics often lead to unpredictable behavior in a multi-threaded program

I得出以下看似有争议的结论：

I come to the following, seemingly controversial, conclusion:

您根本无法安全，可移植地在多线程程序中使用std :: string

显然，没有STL数据结构是线程安全的。但是至少，例如对于std :: vector，您可以简单地使用互斥对象来保护对向量的访问。对于使用COW的std :: string实现，如果不编辑供应商实现内的引用计数语义，您甚至无法可靠地做到这一点。

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.

真实示例：

在我的公司中，我们有一个多线程应用程序，该应用程序已经过全面的单元测试，并且在Valgrind上运行了无数次。该应用程序运行了几个月，没有任何问题。有一天，我在另一版本的gcc上重新编译了该应用程序，突然之间我一直都出现随机段错误。 Valgrind现在正在报告在std :: string复制构造函数中的libstdc ++内部的无效内存访问。

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.

那么，解决方案是什么？好吧，当然，我可以将def std :: vector< char> 键入为字符串类，但确实如此。我也可以等待C ++ 0x，我祈祷这将需要实现者放弃COW。或者，（颤抖），我可以使用自定义字符串类。我个人总是反对在已有的库可以正常工作时实现自己的类的开发人员，但是老实说，我需要一个字符串类，我可以确定它不使用COW语义。而std :: string根本不能保证这一点。

So what is the solution? Well, of course, I could typedef std::vector<char> 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.

我对 std :: string 根本无法可靠地使用 在可移植的多线程程序中？好的解决方法是什么？

Am I right that std::string simply cannot be used reliably at all in portable, multi-threaded programs? And what is a good workaround?

推荐答案

鉴于该标准没有提及内存模型，并且完全没有线程意识，我会说您不能肯定地假设每个实现都是非牛的，所以不可以，

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.

这篇关于多线程程序中的std :: string的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！