shared_ptr 析构 fetch_sub 用 memroy_order_relaxed 会不会有问题？

[ravenxrz]

https://github.com/parallel101/stl1weekend/blob/9c394fd48e1d69cb7686a420fc9e57161ad0acb6/SharedPtr.hpp#L18C1-L20C6

标准库里面释放管理的指针和控制块直接使用了 acq_rel fence的，这里直接用relaxed order不会有问题吗？
标准库实现如下:

考虑如下case， thread 1为最终减到1的thread， thread 2为减到2的 thread。thread 1最终释放资源。

void thread1(shared_ptr<T> ptr) {
    
    // ...
    
    if (ptr.counter.fetch_sub(1, relaxed) == 1)  // Will be true
        delete ptr.storage;
}

void thread2(shared_ptr<T> ptr) {

    // ...
    
    other_storage = *ptr;
    
    if (ptr.counter.fetch_sub(1, relaxed) == 1) // Will be false
        delete ptr.storage;
}

如果使用relaxed order，thread 2可重排为:

void thread2(shared_ptr<T> ptr) {

    // ...
    
    bool should_delete = ptr.counter.fetch_sub(1, relaxed) == 1

    other_storage = *ptr;  // 如果thread 1在这之前释放了storage，就有问题了。
    
    if (should_delete) 
        delete ptr.storage;
}

[chriscco]

我理解这应该并不会造成问题

if (ptr.counter.fetch_sub(1, relaxed) == 1)  // Will be true

这里fetch_sub实际上返回的是减1之前count的值，但是比较时count已经等于0了，如果thread2仍然持有智能指针那么这里就不会判断为true

[ravenxrz]

我理解这应该并不会造成问题

if (ptr.counter.fetch_sub(1, relaxed) == 1)  // Will be true

这里fetch_sub实际上返回的是减1之前count的值，但是比较时count已经等于0了，如果thread2仍然持有智能指针那么这里就不会判断为true

原子变量的sub和delete对象这两个操作不是原子的。thread 2减到cnt到2时，should_delete=false, 但是thread 2后续仍可能访问对象内存，此时thread 1再去减原子变量然后释放对象内存。thread 2再访问时就会有问题。 之所以会有这种时序，就是relaxed order导致的。

另外抛去我这个例子不谈，stl库里面这个memory barrier注释是为什么？

There must be a memory barrier between dispose()and destroy() to ensure that the effects of dispose() are observed in the thread that runs destroy().

[chriscco]

我去看了官方对于shared_ptr的文档，其中对于线程安全的部分有以下解释：

shared_ptr<A> a(new A);
shared_ptr<A> b(a);

// Thread 1     // Thread 2
   a.reset();      b.reset();

Note

The dynamically-allocated object must be destroyed by exactly one of the threads ... The shared state used to implement shared_ptr must be transparent to the user and invariants must be preserved at all times ... Updates to these need to be atomic and visible to all threads to ensure correct cleanup of the managed resource (which is, after all, shared_ptr's job!) ...

... In a multi-threaded program there is a potential race condition if the last reference is dropped (and the managed resource destroyed) between testing the reference count and incrementing it, which could result in a shared_ptr pointing to invalid memory.

我的理解是在给出例子中确实会造成未定义行为，因为会导致并发的 reset() 调用，也就是说对于计数器减1的操作确实需要内存屏障，不过似乎这里没有很好解释为什么需要 acq + rel 的内存屏障，可以结合这个文档的11.4部分

只是我对issue有一处不理解的地方是

thread 2减到cnt到2时，should_delete=false, 但是thread 2后续仍可能访问对象内存

但是由于真正调用decref()的地方只有移动赋值，拷贝赋值，reset()和析构函数，这些函数被调用后都无法继续使用原先的 shared_ptr 来访问调用前他们所管理的指针，所以 thread 2 后续通过和调用 decref() 前同样的方式访问对象内存似乎本身就不合理？也可能是我误解了伪代码中想要表达的意思了

另外对于第二个问题，这个回答也许会有用，并且最上面的文档也是取自这个回答里面的链接

[ravenxrz]

关于这部分的理解：

我去看了官方对于shared_ptr的文档，其中对于线程安全的部分有以下解释：

shared_ptr<A> a(new A);
shared_ptr<A> b(a);

// Thread 1     // Thread 2
   a.reset();      b.reset();
Note

The dynamically-allocated object must be destroyed by exactly one of the threads ... The shared state used to implement shared_ptr must be transparent to the user and invariants must be preserved at all times ... Updates to these need to be atomic and visible to all threads to ensure correct cleanup of the managed resource (which is, after all, shared_ptr's job!) ...

... In a multi-threaded program there is a potential race condition if the last reference is dropped (and the managed resource destroyed) between testing the reference count and incrementing it, which could result in a shared_ptr pointing to invalid memory.

我理解这是肯定的，因为shared_ptr 管理块和管理的对象是两部分，且这两部分的操作没有保证原子。所以是存在race condition的，这部分需要用户保证线程安全。

这部分的回答：

只是我对issue有一处不理解的地方是

thread 2减到cnt到2时，should_delete=false, 但是thread 2后续仍可能访问对象内存

但是由于真正调用decref()的地方只有移动赋值，拷贝赋值，reset()和析构函数，这些函数被调用后都无法继续使用原先的 shared_ptr 来访问调用前他们所管理的指针，所以 thread 2 后续通过和调用 decref() 前同样的方式访问对象内存似乎本身就不合理？也可能是我误解了伪代码中想要表达的意思了

我认为这是因为你没有考虑重排，代码的执行顺序和代码的编写顺序是可能不同的，relaxed_order下就完全可能发生。
这个例子来子帖: 可参考。https://www.reddit.com/r/cpp_questions/comments/19bbatx/is_it_safe_to_relax_memory_order_for_shared_ptr/

最后你的例子我还没看懂，核心观点似乎是因为deleter需要同步？但是目前想不到什么例子。