c++ - COM (C++) Interlock API 是否足以保证 AddRef 和 Release 中的线程安全？

Question

我知道在 COM 对象的 AddRef 和 Release 方法内部使用互锁 API 来递增/递减线程安全的引用计数。但我想在这里理解的是，是否足够使用 Interlock API，或者我们还需要某种其他同步对象，例如互斥体。到目前为止，我看到的所有示例代码都只使用了 Interlock API。

场景- 假设我已经实现了消息对象的 AddRef 和 Release 方法，如下所示。假设线程 A 访问消息对象，因此 m_lRef 计数为 1。一旦完成消息对象使用线程 A 调用 Release 方法

内部释放方法 – 在第 9 行 - m_lRef = 1 在第 10 行 - m_lRef = 0, lRef = 0

线程 A 在第 10 行暂停，另一个线程 B 访问相同的消息，因此它调用 AddRef 方法，该方法将在第 3 行将 m_lRef 值设置为 1。现在线程 B 被挂起，线程 A 在第 11 行恢复——m_lRef =1, lRef = 0。线程 A 将删除该对象。现在，如果线程 B 试图访问同一个对象；崩溃是不可避免的。

我的问题 - 我的场景是否有效？如果 m_lRef =1 那么理想情况下没有其他线程应该等待访问该对象。但是为了防止在这种意外情况下崩溃，我们不应该用互斥锁或 CS 来保护整个释放方法吗？

1. STDMETHODIMP_(ULONG) CMapiMsg::AddRef()
2. {
3.   LONG lRef = InterlockedIncrement(&m_lRef);
4.   return lRef;
5. }
6.  
7. STDMETHODIMP_(ULONG) CMapiMsg::Release()
8. {
9.    LONG lRef = InterlockedDecrement(&m_lRef);
10.   if(0 == lRef)
11.   {
12.    delete this;
13.   }
14.   return lRef;
15. }

Reference Counting Rules

Answer 1

逻辑错了:

m_lRef = 0

Thread A suspends at Line#10 and another Thread B access the same message so it calls AddRef method which will set the value of m_lRef value to 1 at line#3. Now Thread B is suspended and Thread A resumes-

如果线程 B 持有对此对象的有效 COM 引用，则单独线程 A 无法合法地将计数器递减为零。线程 B 仍然持有一些东西，所以当线程 A 释放它拥有的所有东西时，引用计数器应该至少是一个......

如果线程 B 只执行它的第一次递增，它无论如何都应该从某个地方获取接口(interface)指针，这假定了一个未完成的引用。如果某些东西在没有强引用的情况下传递指针，那么这是一个调用者问题，而不是计数问题。

总而言之，Interlocked API 对于引用计数来说是高效且足够的。