貌似本版讨论过

shared_ptr是一个struct/class，其至少包含两个数据成员，一个计数器，一个raw ptr，所以针对shared_ptr的赋值(operator=导致的write)不是原子操作，必须另外加锁。

https://stackoverflow.com/questions/55693819/stdshared-ptr-in-one-writer-many-reader-design-is-thread-safe
--
修改:z16166 FROM 221.222.172.*
FROM 221.222.172.*

当然是错的。
此处应该用unique_ptr，并加锁。

我在网上看到的99%的shared_ptr使用都是滥用。
【 在 speedboy2998 (极品飞车) 的大作中提到: 】
: 标  题: shard_ptr这样用有问题吗？
: 发信站: 水木社区 (Wed Jun 16 15:44:21 2021), 站内
:
: 多个线程调用 process();
: 有一个线程不定期调用 set()；
:
: 应该是没有问题的吧。
:
:

: Test::Test()
: {
:   mProcessor = std::make_shared<Processor>();
: }
: 
: Test::process()
: {
:    mProcessor->do();
: }
: 
: 
: Test::set()
: {
:     mProcessor = std::make_shared<Processor>();
: }
:

: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 218.76.62.*]
--
FROM 76.126.252.*

这个就是错的呀。
绝大多数情况下shared_ptr不能代替锁。
用锁了就不需要shared_ptr了。
【 在 lambdai (lambdai) 的大作中提到: 】
: 标  题: Re: shard_ptr这样用有问题吗？
: 发信站: 水木社区 (Tue Jun 22 10:04:42 2021), 站内
:
: unique_ptr在少数情况有那么一点点局限
:
: 比如publisher无脑发布最新的值，subscriber去获取当时最新的值并且snap
: 这个场景基于shared_ptr是很自然的
:
: 不过锁或者atomic shared ptr还是需要的
: 【 在 here080 的大作中提到: 】
: : 当然是错的。
: : 此处应该用unique_ptr，并加锁。
: : 我在网上看到的99%的shared_ptr使用都是滥用。
: : ...................
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 221.220.134.*]
--
FROM 76.126.252.*

问题是，你为什么要share?
copy一份不香吗？
share的对象往往内部还要再加锁，而且容易出现无法预料的线程竞争。
【 在 ble (ble) 的大作中提到: 】
: 标  题: Re: shard_ptr这样用有问题吗？
: 发信站: 水木社区 (Tue Jun 22 11:26:55 2021), 站内
:
: 锁是一个问题，它这个场景本身是SP适用范围吧，更新守护线程提供最新模块，工作线程随时去拿一个当前最新的用，虽然不保证最新，但是当前业务能完整跑完，用完再释放过期的模块。适合很多网络服务的热更新。
:
:
:
:
: 【 在 here080 的大作中提到: 】
: :
: : 这个就是错的呀。
: : 绝大多数情况下shared_ptr不能代替锁。
: : 用锁了就不需要shared_ptr了。
: : 【 在 lambdai (lambdai) 的大作中提到: 】
:
: #发自zSMTH@IN2010
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 117.136.38.*]
--
FROM 76.126.252.*

楼主的例子是多个线程用同一个模块啊，一个线程负责更新模块。

【 在 here080 的大作中提到: 】
:
: 问题是，你为什么要share?
: copy一份不香吗？
: share的对象往往内部还要再加锁，而且容易出现无法预料的线程竞争。
: 【 在 ble (ble) 的大作中提到: 】

#发自zSMTH@IN2010
--
FROM 114.255.33.*