多线程程序中的 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 是否应该在其复制构造函数中使用 Copy-on-Write 语义

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) Copy-on-Write 语义在多线程程序中经常导致不可预测的行为

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

我得出以下看似有争议的结论:

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.

那么解决方案是什么?嗯，当然，我可以将 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屋！