3

clang ThreadSanitizer在以下代码中报告数据竞争：

#include <future>
#include <iostream>
#include <vector>

int main() {
    std::cout << "start!" << std::endl;
    for (size_t i = 0; i < 100000; i++) {
        std::promise<void> p;
        std::future<void> f = p.get_future();

        std::thread t = std::thread([p = std::move(p)]() mutable {
            p.set_value();
        });

        f.get();
        t.join();
    }
    std::cout << "done!" << std::endl;
    return 0;
}

我可以通过替换来修复p = std::move(p)比赛&p。但是，我找不到解释promiseandfuture对象是否是线程安全的或者它们被销毁的顺序是否重要的​​文档。我的理解是，由于承诺和未来通过“共享状态”进行通信，因此状态应该是线程安全的，销毁顺序应该无关紧要，但 TSan 不同意。（没有 TSan，程序似乎运行正常，而不是崩溃。）

这段代码是否真的有潜在的竞争，或者这是一个 TSan 误报？

您可以通过在 Ubuntu 19.10 Docker 容器中运行以下命令，使用 Clang 9 重现这一点：

$ docker run -it ubuntu:eoan /bin/bash

Inside container:

# apt update
# apt install clang-9 libc++-9-dev libc++abi-9-dev

# clang++-9 -fsanitize=thread -lpthread -std=c++17 -stdlib=libc++ -O0 -g test.cpp -o test
(See test.cpp file contents above)

# ./test

显示数据竞争的示例输出（实际输出在运行之间略有不同）：

==================
WARNING: ThreadSanitizer: data race (pid=9731)
  Write of size 8 at 0x7b2000000018 by thread T14:
    #0 operator delete(void*) <null> (test+0x4b4e9e)
    #1 std::__1::__shared_count::__release_shared() <null> (libc++.so.1+0x83f2c)
    #2 std::__1::__tuple_leaf<1ul, test()::$_0, false>::~__tuple_leaf() /usr/lib/llvm-9/bin/../include/c++/v1/tuple:170:7 (test+0x4b7d38)
    #3 std::__1::__tuple_impl<std::__1::__tuple_indices<0ul, 1ul>, std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>::~__tuple_impl() /usr/lib/llvm-9/bin/../include/c++/v1/tuple:361:37 (test+0x4b7ce9)
    #4 std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>::~tuple() /usr/lib/llvm-9/bin/../include/c++/v1/tuple:466:28 (test+0x4b7c98)
    #5 std::__1::default_delete<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0> >::operator()(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>*) const /usr/lib/llvm-9/bin/../include/c++/v1/memory:2338:5 (test+0x4b7c16)
    #6 std::__1::unique_ptr<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>, std::__1::default_delete<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0> > >::reset(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>*) /usr/lib/llvm-9/bin/../include/c++/v1/memory:2593:7 (test+0x4b7b80)
    #7 std::__1::unique_ptr<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0>, std::__1::default_delete<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0> > >::~unique_ptr() /usr/lib/llvm-9/bin/../include/c++/v1/memory:2547:19 (test+0x4b74ec)
    #8 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, test()::$_0> >(void*) /usr/lib/llvm-9/bin/../include/c++/v1/thread:289:1 (test+0x4b7397)

  Previous atomic read of size 1 at 0x7b2000000018 by main thread:
    #0 pthread_cond_wait <null> (test+0x4268d8)
    #1 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) <null> (libc++.so.1+0x422de)
    #2 main /test/test.cpp:61:9 (test+0x4b713c)

  Thread T14 (tid=18144, running) created by main thread at:
    #0 pthread_create <null> (test+0x425c6b)
    #1 std::__1::__libcpp_thread_create(unsigned long*, void* (*)(void*), void*) /usr/lib/llvm-9/bin/../include/c++/v1/__threading_support:336:10 (test+0x4b958c)
    #2 std::__1::thread::thread<test()::$_0, void>(test()::$_0&&) /usr/lib/llvm-9/bin/../include/c++/v1/thread:303:16 (test+0x4b6fc4)
    #3 test() /test/test.cpp:44:25 (test+0x4b6d96)
    #4 main /test/test.cpp:61:9 (test+0x4b713c)

SUMMARY: ThreadSanitizer: data race (/test/test+0x4b4e9e) in operator delete(void*)
==================
4

1 回答 1

1

当 apromise超出范围*时，会发生以下情况：

  • 如果共享状态没有准备好，
    • 在共享状态中存储类型future_error为错误类型的异常，然后broken_promise
    • 使状态准备就绪
  • 否则，状态准备就绪

如果在超出范围之前没有在 promise 上设置任何值，那么调用get()future 只会导致异常。

现在，在共享状态具有价值之前，实际上很难让承诺超出范围。无论如何，线程已经通过异常退出，或者您有一个逻辑错误，并非所有分支都调用promise::set_value.

您的特定代码似乎没有出现任何这样的症状。移动一个承诺只是将共享状态的所有权转移到新的承诺。

至于竞争条件，get_future保证不会有任何数据竞争promise::set_value及其变化。future::get也保证等到 shared_state 准备好。当一个 Promise 超出范围时，它会在准备好之后“释放”其共享状态，只有当它持有对它的最后一个引用时才会破坏共享状态。由于您对它有另一个引用（通过未来），所以您是安全的。

现在，实现总是可能有数据竞争（偶然），但根据标准，您发布的代码不应该有任何。

*参考 [futures.state]

于 2020-02-07T15:23:56.317 回答