std::thread 构造函数完成实际上与执行线程的开始同步吗？

Question

The C++11 standard (N337, 30.3.1.2) states about the synchronization of the std::thread constructor:

Synchronization: The completion of the invocation of the constructor synchronizes with the beginning of the invocation of the copy of f.

Reading it, I thought the constructor completes before the start of the new thread. But according to the question ( std::thread construction and execution ) and the current implementation in libc++/libstdc++, there seems no synchronization mechanism and the new thread of execution can possibly begin before the end of the std::thread constructor.

If that is correct, what does the standard try to say? Is this the gap between standard and implementation? Or do I understand the term "synchronize with" incorrectly? Even if constructor and new thread are running simultaneously, can the constructor completion be considered synchronizing with the beginning of new thread?

Answer 1

Reading it, I thought the constructor completes before the start of the new thread

"synchronizes with" is a term of art . When the standard mandates that two operations synchronize with each other, that carries with it certain requirements for evaluations before and after the two operations. For example, accessing a variable in the original thread before the std::thread constructor, and accessing it in the new thread do not cause a data race .

Intuitively, you can think of "synchronizes with" as meaning that the new thread can see all prior evaluations, modifications, and side effects from the initial thread.

There is no need to make sure the thread begins by the end of the constructor. That is not what this says.

The way standard libraries enforce this requirement is by relying on underlying libraries like pthreads that essentially also enforce this requirement.

Answer 2

Once the constructor completes there is nothing you can do to prevent the thread from executing, if it already starts or not actual execution immediately is irrelevant and depends on scheduler/cpu/load.

You are guaranteed however that all the code in the constructor has been executed when the code of the thread starts executing.

In other words it may be that the thread executes a million instructions before the next instruction after the constructor is executed (eg the main thread is suspended right after creating the new thread) or it may be a million instructions after the constructor are executed before the first instruction in the thread is executed (ie the new thread is immediately suspended).

May be the hardware is single core and indeed there is simply no way two instructions are executed "at the same time" and all operations on native types are atomic (this was the main issue when programs started being executed on first real parallel hardware... a lot of old multithread code was working without explicit synchronization because the hardware was always implicitly synchronizing but started failing in random ways when true parallelism arrived).

Anyway I wouldn't try to read too much into the formal specification: from a purely formal point of view, I think it would be hard to say that an implementation in which a thread is never actually started is not conforming (proving black-box it's not conforming would require waiting till the end of time). The same could be said of an implementation in which a+b takes 10 billion years...

Answer 3

No it does not synchronize (scheduling etc...)

I usually use a condition variable construct to be really sure the asynchronous thread has really started. Like this:

#include <condition_variable>
#include <mutex>
#include <thread>

/// <summary>
/// wrapper for a condition variable, takes into account
/// https://www.modernescpp.com/index.php/c-core-guidelines-be-aware-of-the-traps-of-condition-variables
/// </summary>
class sync_signal final
{
public:
    sync_signal() = delete;
    ~sync_signal() = default;
    sync_signal(const sync_signal&) = delete;
    sync_signal& operator=(const sync_signal&) = delete;
    sync_signal(sync_signal&&) = delete;

    explicit sync_signal(bool value) :
        m_value{ value }
    {
    }

    void set() noexcept
    {
        {
            std::unique_lock<std::mutex> lock(m_value_mutex);
            m_value = true;
        }
        m_value_changed.notify_all();
    }

    void wait()
    {
        std::unique_lock<std::mutex> lock(m_value_mutex);
        auto pred = [this] { return m_value; };
   
        // check pred first we might have missed a notify
        if (pred())
        {
            return;
        }

        m_value_changed.wait(lock, pred);
    }

    std::mutex m_value_mutex;
    std::condition_variable m_value_changed;
    bool m_value;
};


int main() 
{
    sync_signal signal{ false };

    std::thread t([&signal]()
    {
        signal.set(); // signal that thread has really scheduled/started
        // do your async stuff here
    });

    // wait on main thread for async thread to have really started
    signal.wait();

    // wait for thread to finish to avoid race conditions at shut-down
    t.join();
}

For short duration functions I prefer using std::async though. Instead of creating a whole new thread (and taking up resources) it will get a thread from a threadpool

#include <future>

auto ft = std::async(std::launch::async, [&signal]()
{
    signal.set(); // signal that thread has really started
    // do your async stuff here
});

ft.get();