std :: lock_guard构造函数实例化顺序

Question

I suppose this is more a general question about lvalue instantiation ordering.

In short, is this safe?:

void func1()
{
    std::lock_guard< std::mutex > lock( mutex );
    //do some stuff in locked context
}

void func2()
{
    func1();
    std::lock_guard< std::mutex > lock( mutex );
    //do some stuff in locked context
}

I am somewhat concerned that the compiler may call the constructor of the lock_guard before calling func1 from within func2, thus causing a deadlock.

Is it guaranteed that this is safe or do I need to do something like this:

void func1()
{
    std::lock_guard< std::mutex > lock( mutex );
    //do some stuff in locked context
}

void func2()
{
    func1();

    { //lock
        std::lock_guard< std::mutex > lock( mutex );
        //do some stuff in locked context
    } //unlock
}

Answer 1

Those things that you're describing (the function call and the instantiation of the lock) are known as full-expressions in the standard.

As per C++11 1.9 Program execution /14 (same location and text in C++14 , same text in C++17 4.6 Program execution /16 ):

Every value computation and side effect associated with a full-expression is sequenced before every value computation and side effect associated with the next full-expression to be evaluated.

There are cases where seemingly sequential operations can be indeterminately sequenced, but this is not one of them.

---

As an aside, if you're worried about the possibility that a single thread of execution may attempt to re-acquire the same mutex twice, that's a situation where you may find recursive_mutex coming in handy.

---

As a further aside, on your comment asking about C++98 and C++03, threads were only introduced in C++11. Before then, C++ still used the concept of sequence points as per C.

In C++98 1.9 Program execution /16 and C++03 1.9 Program execution /16 , you'll find similar wording:

There is a sequence point at the completion of evaluation of each full-expression.

Answer 2

Just some additional notes to @paxdiablo's answer. Generally, execution of a resulting program on a particular architecture must have the same effect as is written in the source code according to C++ Standard. Due to optimizations, both compiler and CPU is allowed to generate and execute instructions in different order than the order that matches source code.

However, when multithreaded synchronization constructs are used (such as mutexes and atomic memory operations), such reordering must not happen (if not relaxed by programmer explicitly). Otherwise, multithreaded programming would not be feasible at all.

Compiler knows that it should not reorder instructions if it sees such code. On a CPU level, there are memory barriers for this task.

Therefore, if you lock a mutex, you can be sure that the code written above has already completed. This is generic multithreading concept, so I strongly believe it is valid for C++ as well. Please, correct me if I am wrong.