请看下面的代码:
#include <pthread.h>
#include <boost/atomic.hpp>
class ReferenceCounted {
public:
ReferenceCounted() : ref_count_(1) {}
void reserve() {
ref_count_.fetch_add(1, boost::memory_order_relaxed);
}
void release() {
if (ref_count_.fetch_sub(1, boost::memory_order_release) == 1) {
boost::atomic_thread_fence(boost::memory_order_acquire);
delete this;
}
}
private:
boost::atomic<int> ref_count_;
};
void* Thread1(void* x) {
static_cast<ReferenceCounted*>(x)->release();
return NULL;
}
void* Thread2(void* x) {
static_cast<ReferenceCounted*>(x)->release();
return NULL;
}
int main() {
ReferenceCounted* obj = new ReferenceCounted();
obj->reserve(); // for Thread1
obj->reserve(); // for Thread2
obj->release(); // for the main()
pthread_t t[2];
pthread_create(&t[0], NULL, Thread1, obj);
pthread_create(&t[1], NULL, Thread2, obj);
pthread_join(t[0], NULL);
pthread_join(t[1], NULL);
}
这有点类似于Boost.Atomic.
中的引用计数示例主要区别在于嵌入的ref_count_
在构造函数中初始化为1
(一旦构造函数完成,我们就有一个对ReferenceCounted
对象的引用),而代码不使用boost::intrusive_ptr
。
请不要责怪我在代码中使用delete this
-这是我在工作中的大型代码库中的模式,现在我无能为力。
现在这段代码用clang 3.5
从trunk(详情如下)和ThreadSanitizer (tsan v2)编译得到ThreadSanitizer的如下输出:
WARNING: ThreadSanitizer: data race (pid=9871)
Write of size 1 at 0x7d040000f7f0 by thread T2:
#0 operator delete(void*) <null>:0 (a.out+0x00000004738b)
#1 ReferenceCounted::release() /home/A.Romanek/tmp/tsan/main.cpp:15 (a.out+0x0000000a2c06)
#2 Thread2(void*) /home/A.Romanek/tmp/tsan/main.cpp:29 (a.out+0x0000000a2833)
Previous atomic write of size 4 at 0x7d040000f7f0 by thread T1:
#0 __tsan_atomic32_fetch_sub <null>:0 (a.out+0x0000000896b6)
#1 boost::atomics::detail::base_atomic<int, int, 4u, true>::fetch_sub(int, boost::memory_order) volatile /home/A.Romanek/tmp/boost/boost_1_55_0/boost/atomic/detail/gcc-atomic.hpp:499 (a.out+0x0000000a3329)
#2 ReferenceCounted::release() /home/A.Romanek/tmp/tsan/main.cpp:13 (a.out+0x0000000a2a71)
#3 Thread1(void*) /home/A.Romanek/tmp/tsan/main.cpp:24 (a.out+0x0000000a27d3)
Location is heap block of size 4 at 0x7d040000f7f0 allocated by main thread:
#0 operator new(unsigned long) <null>:0 (a.out+0x000000046e1d)
#1 main /home/A.Romanek/tmp/tsan/main.cpp:34 (a.out+0x0000000a286f)
Thread T2 (tid=9874, running) created by main thread at:
#0 pthread_create <null>:0 (a.out+0x00000004a2d1)
#1 main /home/A.Romanek/tmp/tsan/main.cpp:40 (a.out+0x0000000a294e)
Thread T1 (tid=9873, finished) created by main thread at:
#0 pthread_create <null>:0 (a.out+0x00000004a2d1)
#1 main /home/A.Romanek/tmp/tsan/main.cpp:39 (a.out+0x0000000a2912)
SUMMARY: ThreadSanitizer: data race ??:0 operator delete(void*)
==================
ThreadSanitizer: reported 1 warnings
奇怪的是,thread T1
在对引用计数器进行原子减量时,对与thread T2
相同的内存位置进行大小为1的写操作。
如何解释前者?是由ReferenceCounted
类的析构函数执行的一些清理吗?
是假阳性?还是代码错了?
我的设置是:
$ uname -a
Linux aromanek-laptop 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ clang --version
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
Target: x86_64-pc-linux-gnu
Thread model: posix
代码编译如下:
clang++ main.cpp -I/home/A.Romanek/tmp/boost/boost_1_55_0 -pthread -fsanitize=thread -O0 -g -ggdb3 -fPIE -pie -fPIC
请注意,在我的机器上,boost::atomic<T>
的实现解析为__atomic_load_n
系列函数,ThreadSanitizer声称可以理解。
UPDATE 1:使用clang 3.4
最终版本时也是如此。
UPDATE 2:在libstdc++和libc++中,-std=c++11
和<atomic>
也会出现同样的问题。
这看起来像是假阳性。
release()
方法中的thread_fence
在 fence返回之前强制fetch_sub
(对的调用)执行所有未完成的写操作。因此,下一行的delete
不能因为减少refcount而与前面的写竞争。
引自 c++ Concurrency in Action:
释放操作与
order
的栅栏同步std::memory_order_acquire
[…如果释放操作存储了a对象上的fence之前由原子操作读取的值和栅栏一样的线
由于减少refcount是一个读-修改-写操作,因此应该在这里应用。
为了详细说明,我们需要确保的操作顺序如下:
- 将refcount减少到> 1
- 将refcount减少到1
- 删除对象
2.
和3.
是隐式同步的,因为它们发生在同一个线程上。1.
和2.
是同步的,因为它们都是对相同值的原子读-修改-写操作。如果这两家公司能够竞争,那么整个重新计算将首先被打破。那么剩下的就是同步1.
和3.
了。
这正是栅栏的作用。来自1.
的写操作是一个release
操作,正如我们刚才讨论的,它与2.
同步,对相同的值进行读操作。3.
,与2.
在同一线程上的acquire
栅栏,现在与规范保证的1.
的写入同步。这不需要在对象上添加acquire
写入(正如@KerrekSB在评论中建议的那样),这也可以工作,但由于额外的写入,可能会降低效率。
底线:不要玩弄内存顺序。即使是专家也会犯错误,而且它们对性能的影响通常可以忽略不计。因此,除非您在分析运行中证明它们会破坏您的性能,并且您绝对肯定必须对其进行优化,否则就假装它们不存在并坚持使用默认的memory_order_seq_cst
。
只是为了强调@adam-romanek的评论,在撰写本文(2018年3月)时,ThreadSanitizer不支持独立的内存围栏。这在ThreadSanitizer FAQ中有暗示,没有明确提到支持fence:
Q: 支持哪些同步原语? TSan支持pthread同步原语,内置编译器原子操作(sync/atomic), c++操作支持llvm libc++(虽然没有经过非常彻底的测试)。