Фоновая задача запускается через std::jthread. Как завершится вызов run при выходе из функции? пример с кодом

#include <chrono>
#include <thread>

void work(std::stop_token token) {
    while (!token.stop_requested()) {
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

void run() {
    std::jthread worker(work);
}

Краткий ответ

При выходе из run() деструктор std::jthread сначала запрашивает остановку через std::stop_token, затем ожидает завершения потока. Поэтому функция завершится после того, как work проверит запрос и выйдет из цикла; остановка не является принудительным прерыванием потока.

Исторический контекст

До C++20 для управления потоком использовали std::thread. Если его деструктор встречал ещё присоединённый поток, программа завершалась через std::terminate, поэтому разработчик должен был явно вызвать join() или detach() на всех путях выхода.

std::jthread появился в C++20 как RAII-обёртка с автоматическим присоединением и встроенной моделью кооперативной остановки. Она решает проблему безопасного управления временем жизни потока, но не может заставить произвольный код немедленно прекратиться.

Постановка проблемы

В приведённом коде объект worker уничтожается при выходе из run(). Неверно считать, что поток будет немедленно убит или что деструктор просто отсоединит его от программы.

Если функция work регулярно проверяет токен, поток завершится штатно, а run() подождёт его завершения. Если рабочий код никогда не проверяет токен, деструктор будет ждать бесконечно, пока поток не завершится по другой причине.

Подробное решение

У std::jthread деструктор логически выполняет две операции: вызывает запрос остановки у связанного std::stop_source, затем делает join(), если поток ещё присоединён. Запрос только меняет состояние токена; он не прерывает выполнение инструкции, системный вызов или ожидание автоматически.

Параметр std::stop_token передаётся функции потока благодаря специальной поддержке std::jthread. Рабочая функция должна сама периодически проверять stop_requested() либо использовать операции ожидания, поддерживающие остановку.

В данном примере после уничтожения worker условие цикла станет ложным при следующей проверке. Однако поток может сначала завершить текущий sleep_for, поэтому выход из run() задержится примерно до окончания этого ожидания.

Преимущество подхода — автоматическое безопасное присоединение даже при исключении или раннем выходе. Компромисс — деструктор может блокироваться, а корректность остановки зависит от кооперации рабочего кода.

#include <iostream>
#include <thread>

void work(std::stop_token token) {
    while (!token.stop_requested()) {
        std::this_thread::yield();
    }
    std::cout << "stopped
";
}

int main() {
    std::jthread worker(work);
}

В main уничтожение worker запрашивает остановку и ждёт, пока work увидит этот запрос. В отличие от detach(), после завершения области действия поток не продолжает обращаться к уже уничтоженным объектам владельца.

Ситуация из практики

Сервис запускает поток, который периодически читает очередь задач. При остановке сервиса нужно гарантировать, что поток не использует уничтоженные логгер и очередь.

Использование std::thread с detach() устраняет ожидание, но создаёт риск обращения к ресурсам после их уничтожения. Явный std::thread::join() даёт правильный порядок завершения, однако требует аккуратно обрабатывать исключения и все пути выхода.

std::jthread обычно является предпочтительным решением: его деструктор запрашивает остановку и дожидается потока. Рабочий цикл должен проверять токен, а блокирующее ожидание очереди — иметь способ проснуться по запросу остановки, например через std::condition_variable_any с токеном.

Результат — предсказуемое завершение без detach() и без риска обращения к уничтоженным объектам. Если операция внутри потока может зависнуть навсегда и не реагирует на остановку, один std::jthread проблему не решит: потребуется изменить протокол ожидания или вынести необрываемую операцию в отдельный изолированный компонент.

Что кандидаты часто упускают

1. Прерывает ли request_stop() текущую операцию?

   Нет. request_stop() устанавливает состояние общего stop-state и уведомляет зарегистрированные std::stop_callback, но не прерывает произвольный код, системный вызов или вычисление. Поток завершится только после того, как его код отреагирует на запрос.

2. Что произойдёт, если рабочая функция не принимает std::stop_token?

   std::jthread умеет запускать вызываемый объект как с токеном, так и без него, если соответствующая форма вызова допустима. В варианте без токена автоматическое присоединение всё равно выполняется, но рабочая функция не получает стандартного способа узнать о запросе остановки; деструктор будет ждать её естественного завершения.

3. Можно ли безопасно вызвать detach() у std::jthread вместо ожидания?

   Да, у std::jthread есть detach(), но это отменяет гарантию, что поток завершён к моменту уничтожения объекта. Запрос остановки сам по себе не продлевает время жизни захваченных ссылок и объектов, поэтому отсоединённый поток может обратиться к уже уничтоженным данным. Для управляемого завершения фоновой работы обычно выбирают присоединение и корректную обработку остановки, а не detach().