Is there any potential problem with double-check lock for C++?

Question

Here is a simple code snippet for demonstration.

Somebody told me that the double-check lock is incorrect. Since the variable is non-volatile, the compiler is free to reorder the calls or optimize them away(For details, see codereview.stackexchange.com/a/266302/226000).

But I really saw such a code snippet is used in many projects indeed. Could somebody shed some light on this matter? I googled and talked about it with my friends, but I still can't find out the answer.

#include <iostream>
#include <mutex>
#include <fstream>

namespace DemoLogger
{
    void InitFd()
    {
        if (!is_log_file_ready)
        {
            std::lock_guard<std::mutex> guard(log_mutex);
            if (!is_log_file_ready)
            {
                log_stream.open("sdk.log", std::ofstream::out | std::ofstream::trunc);
                is_log_file_ready = true;
            }
        }
    }


    extern static bool is_log_file_ready;
    extern static std::mutex log_mutex;
    extern static std::ofstream log_stream;
}

//cpp
namespace DemoLogger
{
    bool is_log_file_ready{false};
    std::mutex log_mutex;
    std::ofstream log_stream;
}

UPDATE: Thanks to all of you. There is better implementation for InitFd() indeed, but it's only a simple demo indeed, what I really want to know is that whether there is any potential problem with double-check lock or not.

For the complete code snippet, see https://codereview.stackexchange.com/questions/266282/c-logger-by-template.

Answer 1

The double-checked lock is incorrect because is_log_file_ready is a plain bool, and this flag can be accessed by multiple threads one of which is a writer - that is a race

The simple fix is to change the declaration:

std::atomic<bool> is_log_file_ready{false};

You can then further relax operations on is_log_file_ready:

void InitFd()
{
    if (!is_log_file_ready.load(std::memory_order_acquire))
    {
        std::lock_guard<std::mutex> guard(log_mutex);

        if (!is_log_file_ready.load(std::memory_order_relaxed))
        {
            log_stream.open("sdk.log", std::ofstream::out | std::ofstream::trunc);
            is_log_file_ready.store(true, std::memory_order_release);
        }
    }
}

But in general, double-checked locking should be avoided except in low-level implementations.

As suggested by Arthur P. Golubev, C++ offers primitives to do this, such as std::call_once

Update:

Here's an example that shows one of the problems a race can cause.

#include <thread>
#include <atomic>

using namespace std::literals::chrono_literals;

int main()
{
    int flag {0}; // wrong !

    std::thread t{[&] { while (!flag); }};

    std::this_thread::sleep_for(20ms);

    flag = 1;
    t.join();
}

The sleep is there to give the thread some time to initialize.
This program should return immediately, but compiled with full optimization -O3, it probably doesn't. This is caused by a valid compiler transformation, that changes the while-loop into something like this:

if (flag) return; while(1);

And if flag is (still) zero, this will run forever (changing the flag type to std::atomic<int> will solve this).

This is only one of the effects of undefined behavior, the compiler does not even have to commit the change to flag to memory.

With a race, or incorrectly set (or missing) barriers, operations can also be re-ordered causing unwanted effects, but these are less likely to occur on X86 since it is a generally more forgiving platform than weaker architectures (although re-ordering effects do exist on X86)

Answer 2

There is nothing to optimize away here (no commands to be excluded, see the details below), but there are the following:

1. It is possible that is_log_file is set to true before log_stream opens the file; and then another thread is possible to bypass the outer if block code and start using the stream before the std::ofstream::open has completed.

It could be solved by using std::atomic_thread_fence(std::memory_order_release); memory barrier before setting the flag to true.

Also, a compiler is forbidden to reorder accesses to volatile objects on the same thread (https://en.cppreference.com/w/cpp/language/as_if), but, as for the code specifically, the available set of operator << functions and write function of std::ofstream just is not for volatile objects - it would not be possible to write in the stream if make it volatile (and making volatile only the flag would not permit the reordering).

Note, a protection for is_log_file flag from a data race with C++ standard library means releasing std::memory_order_release or stronger memory order - the most reasonable would be std::atomic/std::atomic_bool (see LWimsey's answer for the sample of the code) - would make reordering impossible because the memory order

2. Formally, an execution with a data race is considered to be causing undefined behaviour - which in the double-checked lock is actual for is_log_file flag. In a conforming to the standard of the language code, the flag must be protected from a data race (the most reasonable way to do it would be using std::atomic/std::atomic_bool).

Though, in practice, if the compiler is not insane so that intentionally spoils your code (some people wrongly consider undefined behaviour to be what occurs in run-time and does not relate to compilation, but standard operates undefined behaviour to regulate compilation) under the pretext it is allowed everything if undefined behavior is caused (by the way, must be documented; see details of compiling C++ code with a data race in: https://stackoverflow.com/a/69062080/1790694 ) and at the same time if it implements bool reasonably, so that consider any non-zero physical value as true (it would be reasonable since it must convert arithmetics, pointers and some others to bool so), there will never be a problem with partial setting the flag to true (it would not cause a problem when reading); so the only memory barrier std::atomic_thread_fence(std::memory_order_release); before setting the flag to true, so that reordering is prevented, would make your code work without problems.

At https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables you can read that implementations of initialization of static local variables since C++11 (which you also should consider to use for one-time actions in general, see the note about what to consider for one-time actions in general below) usually use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.

This is an examples of exactly that environment-dependent safety of a non-atomic flag which I stated above. But it should be understood that these solutions are environment-dependent, and, since they are parts of implementations of the compilers themselves, but not a program using the compilers, there is no concern of conforming to the standard there.

To make your program corresponding to the standard of the language and be protected (as far as the standard is implemented) against a compiler implementation details liberty, you must protect the flag from data races, and the most reasonable then, would be using std::atomic or std::atomic_bool.

---

Note, even without protection of the flag from data races:

• because of the mutex, it is not possible that any thread would not get updates after changing values (both the bool flag and the std::ofstream object) by some thread. The mutex implements the memory barrier, and if we don’t have the update when checking the flag in the first condition clause, we then get it then come to the mutex, and so guaranteedly have the updated value when checking the flag in the second condition clause.

• because the flag can unobservably be potentially accessed in unpredictable ways from other translation units, the compiler would not be able to avoid writes and reads to the flag under the as-if rule even if the other code of translation unit would be so senseless (such as setting the flag to true and then starting the threads so that no resets to false accessible) that it would be permitted in case the flag is not accessible from other translation units.

---

---

For one-time actions in general besides raw protection with flags and mutexes consider using:

• std::call_once (https://en.cppreference.com/w/cpp/thread/call_once);
• calling a function for initializing a static local variable (https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables) if its lifetime suits since its initialization is data race safety (be careful in regards to the fact that data race safety of initialization of static local variables is present only since C++11).

---

All the mentioned multi-threading functionality is available since C++11 (but, since you are already using std::mutex which is available starting since it too, this is the case).

---

Also, you should correctly handle the cases of opening the file failure.

Also, everyone must protect your std::ofstream object from concurrent operations of writing to the stream.

---

Answering the additional question from the update of the question, there are no problems with properly implemented double-check lock, and the proper implementation is possible in C++.

Answer 3

Somebody told me that the double-check lock is incorrect

It usually is.

IIRC double-checked locking originated in Java (whose more strongly-specified memory model made it viable).

From there it spread a plague of ill-informed and incorrect C++ code, presumably because it looks enough like Java to be vaguely plausible.

Since the variable is non-volatile

Double-checked locking cannot be made correct by using volatile for synchronization, because that's not what volatile is for.

Java is perhaps also the source of this misuse of volatile, since it means something entirely different there.

Thanks for linking to the review that suggested this, I'll go and downvote it.

But I really saw such a code snippet is used in many projects indeed. Could somebody shed some light on this matter?

As I say, it's a plague, or really I suppose a harmful meme in the original sense.

I googled and talked about it with my friends, but I still can't find out the answer.

... Is there any potential problem with double-check lock for C++?

There are nothing but problems with double-checked locking for C++. Almost nobody should ever use it. You should probably never copy code from anyone who does use it.

In preference order:

1. Just use a static local, which is even less effort and still guaranteed to be correct - in fact:

   If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once).

   Note: usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.

   so you can get correct double-checked locking for free.

2. Use std::call_once if you need more elaborate initialization and don't want to package it into a class

3. Use (if you must) double-checked locking with a std::atomic_flag or std::atomic_bool flag and never volatile.