​​joinable
#опытным

Не часто мы в коде сами создаем потоки. Но когда это происходит, то начинаются интересности буквально везде и повсюду. Опустим гонки данных и прочие проблемы и обсудим вот что.

В деструкторах классов, которые в качестве поля содержат поток, часто можно найти такую конструкцию:

if (worker_.joinable())
    worker_.join();

Полноценно это может выглядеть так:

class BackgroundWorker {
    std::atomic<bool> stop_{false};
    std::thread worker_;
public:
    BackgroundWorker() {
        worker_ = std::thread([this] {
            while (!stop_.load()) {
                std::this_thread::sleep_for(std::chrono::milliseconds(100));
                // do something important
            }
        });
    }
    ~BackgroundWorker() {
        stop_ = true;
        if (worker_.joinable())
            worker_.join();
    }
    BackgroundWorker(const BackgroundWorker&) = delete;
    BackgroundWorker& operator=(const BackgroundWorker&) = delete;
};

Зачем нужен этот joinable? Как это поток может не присоединиться? К чему может привести присоединение не joinable потока? На все эти вопросы сейчас ответим.

Проверка joinable() перед вызовом join() в деструкторе класса - это защита от ошибок, связанных с некорректным состоянием потока. Если вызвать join() для не joinable потока, будет сгенерировано исключение std::system_error, чего нам явно не хочется получить в такой важный момент.

Какой поток нельзя присоединять?

1️⃣ Созданный дефолтным конструктором. std::thread thd; - объект потока конечно есть, но никакого реального потока запущено не было. Поток должен быть успешно запущен, чтобы быть в состоянии joinable.

2️⃣ Перемещенный объект. В ту же степь. Перемещенный объект std::thread не связан больше ни с каким потоком, поэтому и находится в неприсоединяемом состоянии.

3️⃣ Ранее присоединенный объект. Если тебя уже присоединили, то ты уже не можешь бы joinable.

4️⃣ Отсоединенный. Если у объекта вызвали метод detach() и отсоединили поток исполнения от этого объекта, то присоединить его совсем не получится.

По идее, все эти пункты мы контролируем в коде. Если мы явно вызываем конструктор потока с функцией, не отсоединяем поток, не присоединяем его по середине кода и не перемещаем, то и joinable казалось бы не нужен.

Но все-таки это идиоматическая конструкция, которую просто надо запомнить и использовать "на всякий случай".

В будущем вы скорее всего будете менять этот класс. И, например, добавите в апи метод Wait(), который явно дожидается завершения потока. Или вообще отсоедините поток.

Никто не застрахован от изменений в будущем, поэтому уже заранее нужно заложить безопасное разрушение объекта.

Ну или используйте C++20 std::jthread и забудьте про эту конструкцию)

Be safe. Stay cool.

#concurrency