使用packaged_task和线程可能的数据争用
possible data race using packaged_task and threads
我最近在我的项目上运行了valgrind --tool=helgrind，并收到了警告"可能的数据竞争"，我认为这是令人担忧的。但是，即使是这个简单的测试程序也会导致以下消息：
#include <iostream>
#include <thread>
#include <future>
int main()
{
std::packaged_task<void()> task([]()
{
std::cout << "Hellon"; // You can leave this out
});
auto future = task.get_future();
std::thread(std::move(task)).detach();
future.get();
}
用g++-4.9 -p -g -std=c++11 -pthread -O3 test.cpp编译，valgrind --tool=helgrind ./a.out的输出是：
==12808== Helgrind, a thread error detector
==12808== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==12808== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==12808== Command: ./a.out
==12808==
Hello
==12808== ---Thread-Announcement------------------------------------------
==12808==
==12808== Thread #2 was created
==12808== at 0x567B73E: clone (clone.S:74)
==12808== by 0x536A1F9: do_clone.constprop.4 (createthread.c:75)
==12808== by 0x536B7EB: create_thread (createthread.c:245)
==12808== by 0x536B7EB: pthread_create@@GLIBC_2.2.5 (pthread_create.c:606)
==12808== by 0x4C30E3D: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x4EF7F08: std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==12808== by 0x403C3D: std::thread::thread<std::packaged_task<void ()>>(std::packaged_task<void ()>&&) (thread:138)
==12808== by 0x401D57: main (test.cpp:13)
==12808==
==12808== ----------------------------------------------------------------
==12808==
==12808== Thread #2: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
==12808== at 0x4C2F295: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x4EF3CE8: std::condition_variable::notify_all() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==12808== by 0x402F18: _M_set_result (future:374)
==12808== by 0x402F18: _M_run (future:1319)
==12808== by 0x402F18: operator() (future:1453)
==12808== by 0x402F18: _M_invoke<> (functional:1700)
==12808== by 0x402F18: operator() (functional:1688)
==12808== by 0x402F18: std::thread::_Impl<std::_Bind_simple<std::packaged_task<void ()> ()> >::_M_run() (thread:115)
==12808== by 0x4EF7DCF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==12808== by 0x4C30FD6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x536B0A4: start_thread (pthread_create.c:309)
==12808== by 0x567B77C: clone (clone.S:111)
==12808==
==12808== ---Thread-Announcement------------------------------------------
==12808==
==12808== Thread #1 is the program's root thread
==12808==
==12808== ----------------------------------------------------------------
==12808==
==12808== Possible data race during read of size 8 at 0x5C4FAA0 by thread #1
==12808== Locks held: none
==12808== at 0x4026A9: ~unique_ptr (unique_ptr.h:235)
==12808== by 0x4026A9: ~_Task_state_base (future:1281)
==12808== by 0x4026A9: ~_Task_state (future:1302)
==12808== by 0x4026A9: destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (new_allocator.h:124)
==12808== by 0x4026A9: _S_destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (alloc_traits.h:282)
==12808== by 0x4026A9: destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (alloc_traits.h:411)
==12808== by 0x4026A9: std::_Sp_counted_ptr_inplace<std::__future_base::_Task_state<main::{lambda()#1}, std::allocator<int>, void ()>, main::{lambda()#1}, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:524)
==12808== by 0x401ED4: _M_release (shared_ptr_base.h:149)
==12808== by 0x401ED4: ~__shared_count (shared_ptr_base.h:666)
==12808== by 0x401ED4: ~__shared_ptr (shared_ptr_base.h:914)
==12808== by 0x401ED4: reset (shared_ptr_base.h:1015)
==12808== by 0x401ED4: ~_Reset (future:657)
==12808== by 0x401ED4: get (future:786)
==12808== by 0x401ED4: main (test.cpp:14)
==12808==
==12808== This conflicts with a previous write of size 8 by thread #2
==12808== Locks held: none
==12808== at 0x403407: release (unique_ptr.h:328)
==12808== by 0x403407: unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter, void> (unique_ptr.h:221)
==12808== by 0x403407: ~packaged_task (future:1409)
==12808== by 0x403407: ~_Head_base (tuple:128)
==12808== by 0x403407: ~_Tuple_impl (tuple:229)
==12808== by 0x403407: ~tuple (tuple:388)
==12808== by 0x403407: ~_Bind_simple (functional:1663)
==12808== by 0x403407: std::thread::_Impl<std::_Bind_simple<std::packaged_task<void ()> ()> >::~_Impl() (thread:107)
==12808== by 0x4EF7E1A: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==12808== by 0x4C30FD6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x536B0A4: start_thread (pthread_create.c:309)
==12808== by 0x567B77C: clone (clone.S:111)
==12808== Address 0x5c4faa0 is 128 bytes inside a block of size 144 alloc'd
==12808== at 0x4C2C520: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x401C8C: allocate (new_allocator.h:104)
==12808== by 0x401C8C: allocate (alloc_traits.h:357)
==12808== by 0x401C8C: __shared_count<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()>, std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr_base.h:616)
==12808== by 0x401C8C: __shared_ptr<std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr_base.h:1090)
==12808== by 0x401C8C: shared_ptr<std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr.h:316)
==12808== by 0x401C8C: allocate_shared<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()>, std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr.h:588)
==12808== by 0x401C8C: __create_task_state<void(), main()::<lambda()>, std::allocator<int> > (future:1351)
==12808== by 0x401C8C: packaged_task<main()::<lambda()>, std::allocator<int>, void> (future:1403)
==12808== by 0x401C8C: packaged_task<main()::<lambda()>, void> (future:1393)
==12808== by 0x401C8C: main (test.cpp:11)
==12808== Block was alloc'd by thread #1
==12808==
==12808== ----------------------------------------------------------------
==12808==
==12808== Possible data race during read of size 1 at 0x5C4FA6C by thread #1
==12808== Locks held: none
==12808== at 0x4C2ED90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x4C2F57F: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x4026D7: ~_State_baseV2 (future:316)
==12808== by 0x4026D7: ~_Task_state_base (future:1281)
==12808== by 0x4026D7: ~_Task_state (future:1302)
==12808== by 0x4026D7: destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (new_allocator.h:124)
==12808== by 0x4026D7: _S_destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (alloc_traits.h:282)
==12808== by 0x4026D7: destroy<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()> > (alloc_traits.h:411)
==12808== by 0x4026D7: std::_Sp_counted_ptr_inplace<std::__future_base::_Task_state<main::{lambda()#1}, std::allocator<int>, void ()>, main::{lambda()#1}, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:524)
==12808== by 0x401ED4: _M_release (shared_ptr_base.h:149)
==12808== by 0x401ED4: ~__shared_count (shared_ptr_base.h:666)
==12808== by 0x401ED4: ~__shared_ptr (shared_ptr_base.h:914)
==12808== by 0x401ED4: reset (shared_ptr_base.h:1015)
==12808== by 0x401ED4: ~_Reset (future:657)
==12808== by 0x401ED4: get (future:786)
==12808== by 0x401ED4: main (test.cpp:14)
==12808==
==12808== This conflicts with a previous write of size 4 by thread #2
==12808== Locks held: none
==12808== at 0x536F9BF: pthread_cond_broadcast@@GLIBC_2.3.2 (pthread_cond_broadcast.S:59)
==12808== by 0x402F18: _M_set_result (future:374)
==12808== by 0x402F18: _M_run (future:1319)
==12808== by 0x402F18: operator() (future:1453)
==12808== by 0x402F18: _M_invoke<> (functional:1700)
==12808== by 0x402F18: operator() (functional:1688)
==12808== by 0x402F18: std::thread::_Impl<std::_Bind_simple<std::packaged_task<void ()> ()> >::_M_run() (thread:115)
==12808== Address 0x5c4fa6c is 76 bytes inside a block of size 144 alloc'd
==12808== at 0x4C2C520: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==12808== by 0x401C8C: allocate (new_allocator.h:104)
==12808== by 0x401C8C: allocate (alloc_traits.h:357)
==12808== by 0x401C8C: __shared_count<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()>, std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr_base.h:616)
==12808== by 0x401C8C: __shared_ptr<std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr_base.h:1090)
==12808== by 0x401C8C: shared_ptr<std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr.h:316)
==12808== by 0x401C8C: allocate_shared<std::__future_base::_Task_state<main()::<lambda()>, std::allocator<int>, void()>, std::allocator<int>, main()::<lambda()>, const std::allocator<int>&> (shared_ptr.h:588)
==12808== by 0x401C8C: __create_task_state<void(), main()::<lambda()>, std::allocator<int> > (future:1351)
==12808== by 0x401C8C: packaged_task<main()::<lambda()>, std::allocator<int>, void> (future:1403)
==12808== by 0x401C8C: packaged_task<main()::<lambda()>, void> (future:1393)
==12808== by 0x401C8C: main (test.cpp:11)
==12808== Block was alloc'd by thread #1
==12808==
==12808==
==12808== For counts of detected and suppressed errors, rerun with: -v
==12808== Use --history-level=approx or =none to gain increased speed, at
==12808== the cost of reduced accuracy of conflicting-access information
==12808== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 23 from 23)
我的问题：我可以安全地忽略这一点吗？如果是这样，如何抑制这些警告？
我也遇到了这个警告，并在Kubuntu 14.04上检查了GCC 4.8(/usr/include/c++/4.8/future(的libstdc++源代码。我没有发现错误。future的状态包含结果指针、互斥锁和条件变量。 future<T>::wait()锁定互斥锁并检查结果指针是否为 null。如果是，它将等待条件变量(这将在一个原子操作中解锁互斥锁(。在promise<T>::set_value()(或set_exception()，我猜(上，代码锁定互斥锁，设置结果指针，解锁互斥锁，并在condition variable上调用notify_all()。因此，Helgrind 发出警告，因为调用互斥锁时不会锁定notify_all()。但是，代码仍然是安全的，因为持有互斥锁来设置指针，这是更改签入future<T>::wait()结果的唯一方法。在lock_guard的生命周期之外执行通知可能是一种优化(尽可能简短地保持互斥锁(。不幸的是，它确实导致了这个警告。libstdc++ 维护者可能不愿意接受补丁，因为 a( 补丁会降低性能，如果稍微降低，b( 如果它没有损坏，就不要修复它。因此，我的建议是压制赫尔格林德。
请注意，为了清晰和简洁，我简化了一些交互，特别是future和promise将实际工作委托给隐藏的实现类，set_value使用额外的once_flag来同步并发调用等。
另请参阅此线程，我对它的回答以及Cubbi对我的回答的精确评论(我忽略了(：为什么 std：：condition_variable 的通知和等待功能都需要锁定的互斥锁
相关文章：
- 如何在没有死锁和/或争用的情况下正确使用 std::mutex C++?
- 并行块(线程清理器）之外的 OpenMP 中的争用条件;误报?
- 如何在C++中创建争用条件
- C++上的手动重置事件(来自 C#）实现:如何避免争用条件
- 作为随机数生成器的争用条件
- 设计低线程争用的多线程聊天服务器
- 智能指针析构函数争用条件
- 尽管互斥锁，线程中的争用条件
- ThreadSanitizer 报告的数据争用
- 在C++中递增和递减全局变量时的争用条件
- 线程清理器检测到数据争用，问题出在哪里?
- 为什么此代码不创建争用条件?
- 防止派生析构函数中的 vtable 数据争用
- __has_include(） 和后续 #include 之间是否存在争用条件
- 一次加载整个缓存行以避免争用其中的多个元素
- 为什么此示例中没有使用 if 语句的数据争用?
- 需要帮助解决特征数组并行构造中的数据争用
- GCC 的 TSAN 报告了线程安全静态本地的数据争用
- 使用packaged_task和线程可能的数据争用
- 将相同的值写入相同的内存位置是否会导致数据争用?
