关于使用共享_ptr的线程安全的问题
众所周知，shared_ptr仅保证对基础控制块的访问是线程 安全，不保证访问拥有的对象。
那么为什么下面的代码段中有一个竞赛条件：
std::shared_ptr<int> g_s = std::make_shared<int>(1);
void f1()
{
std::shared_ptr<int>l_s1 = g_s; // read g_s
}
void f2()
{
std::shared_ptr<int> l_s2 = std::make_shared<int>(3);
std::thread th(f1);
th.detach();
g_s = l_s2; // write g_s
}
在上面的代码段中，共享指针的共享对象命名g_s确实无法访问。
我现在真的很困惑。有人可以阐明这件事吗？
As it's well known that shared_ptr only guarantees access to underlying control block is thread
safe and no guarantee made for accesses to owned object.
Then why there is a race condition in the code snippet below:
std::shared_ptr<int> g_s = std::make_shared<int>(1);
void f1()
{
std::shared_ptr<int>l_s1 = g_s; // read g_s
}
void f2()
{
std::shared_ptr<int> l_s2 = std::make_shared<int>(3);
std::thread th(f1);
th.detach();
g_s = l_s2; // write g_s
}
In the code snippet above, the owned object of the shared pointer named g_s are not accessed indeed.
I am really confused now. Could somebody shed some light on this matter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
std :: shared_ptr＆lt; t＆gt;确保访问其控制块是线程安全的，但不能访问std :: shardy_ptr＆lt; t＆gt;实例本身，这是通常是一个具有两个数据成员的对象：原始指针（get（））和指向控制块的指针。在您的代码中，可以通过两个线程同时访问相同的
std :: shared_ptr＆gt;实例。f1读取，f2写入。如果两个线程访问两个不同的
shared_ptr共享所有权所有权的实例，则不会有数据竞赛。这两个实例将具有相同的控制块，但是对控制块的访问将通过库实现适当同步。如果您需要并发，无竞赛的访问单
std :: shared_ptr＆lt; t＆gt;实例来自多个线程，则可以使用std :: atomic＆std :: atomic＆std :: shared_ptr＆lt＆lt; （还有一个较旧的接口可以在C中使用C ++ 20，在C ++ 20中弃用。std::shared_ptr<T>guarantees that access to its control block is thread-safe, but not access to thestd::shared_ptr<T>instance itself, which is generally an object with two data members: the raw pointer (the one returned byget()) and the pointer to the control block.In your code, the same
std::shared_ptr<int>instance may be concurrently accessed by the two threads;f1reads, andf2writes.If the two threads were accessing two different
shared_ptrinstances that shared ownership of the same object, there would be no data race. The two instances would have the same control block, but accesses to the control block would be appropriately synchronized by the library implementation.If you need concurrent, race-free access to a single
std::shared_ptr<T>instance from multiple threads, you can usestd::atomic<std::shared_ptr<T>>. (There is also an older interface that can be used prior to C++20, which is deprecated in C++20.)