Опишите конкретный механизм, с помощью которого **std::promise** передает объекты исключений между потоками к связанному **std::future**, и почему это требует стирания типа исключения в общей области состояния?

Ответ на вопрос

История вопроса.

Функция std::future и std::promise появилась в C++11, чтобы формализовать асинхронный перенос результатов между потоками. Ранее использовались произвольные методы общего доступа с ручной синхронизацией, что делало обработку исключений почти невозможной между потоками. Комитет по стандартизации потребовал механизм, который мог бы захватывать любой тип исключения, выбрасываемого в рабочем потоке, и точно воспроизводить его в ожидающем потоке, не зная статического типа исключения на момент хранения.

Проблема.

Объекты исключений являются полиморфными и по умолчанию распределяются в стеке, но они должны существовать вне области видимости std::promise, который их создал. Поскольку std::future параметризуется только типом результата, а не типом исключения, общая область состояния не может содержать типизированный член исключения. Более того, поток-потребитель может пережить поток-производитель, что требует, чтобы исключение сохранялось в памяти, выделенной под кучу, с семантикой совместного владения.

Решение.

Стандарт предписывает, чтобы std::promise использовал std::exception_ptr для захвата исключений через std::current_exception(), который выполняет неявное стирание типа, копируя исключение в кучу и сохраняя дескриптор с стертым типом. Общая область состояния (блок управления с подсчетом ссылок) сохраняет этот std::exception_ptr, позволяя std::future::get() обнаруживать исключение и повторно выбрасывать его с помощью std::rethrow_exception().

std::promise<int> prom;
auto fut = prom.get_future();

std::thread([&prom]{
    try {
        throw std::runtime_error("Не удалось выполнить задачу");
    } catch(...) {
        prom.set_exception(std::current_exception());
    }
}).detach();

try {
    int val = fut.get(); // Повторно выбрасывает runtime_error
} catch(const std::exception& e) {
    // Обрабатывает переданное исключение
}

Ситуация из жизни

Контекст.

Распределенная вычислительная система требовала, чтобы рабочие потоки обрабатывали задачи сегментации изображений, которые могли завершиться неудачно из-за исключений GPUOutOfMemory или CorruptInputData. Главный поток должен был получать эти специфические исключения, чтобы инициировать запасную обработку на ЦП или повторную передачу данных.

Описание проблемы.

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

Решение 1: Типизированные очереди исключений.

Команда рассматривала возможность поддерживать отдельные очереди для каждого типа исключения, используя шаблоны. Это обеспечивало безопасность типов, но требовало использования std::any для стирания типов в общей очереди, что добавляло значительные накладные расходы и сложности. Это также нарушало возможность естественно обрабатывать исключения с помощью блоков try-catch в потоке-потребителе.

Решение 2: Виртуальный держатель исключений.

Они реализовали абстрактный класс ExceptionBase с производными классов, хранящимися в std::unique_ptr<ExceptionBase>. Хотя это позволяло полиморфному хранению, требовалась ручная логика клонирования для поддержания совместного владения между потоками и внедрялось затраты на виртуальный диспетчер при повторном выбрасывании. Пользовательский подсчет ссылок был подвержен ошибкам и сложен для обеспечения безопасности исключений.

Выбранное решение и его причина.

Команда выбрала std::packaged_task с std::future, который внутри использует механизм std::promise/std::exception_ptr. Это устранило необходимость в пользовательском коде стирания типов, поскольку стандартная библиотека обрабатывала захват исключений и срок жизни общей области состояния автоматически. Выбор был обусловлен необходимостью обеспечить отсутствие необходимости в обслуживании для обеспечения безопасности исключений и требованием поддерживать стандартные шаблоны обработки исключений без пользовательских базовых классов.

Результат.

Система успешно передавала конкретные типы исключений через границы потоков без утечек памяти, даже во время агрессивного изменения размера пула потоков. Главный поток мог захватывать GPUOutOfMemory специально, при этом по умолчанию возвращая std::exception для неизвестных ошибок, поддерживая чистое разделение между логикой обработки ошибок и синхронизацией потоков.

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

Вопрос: Почему std::current_exception() копирует объект исключения, а не сохраняет указатель на существующее исключение?

Ответ.

Объект исключения в блоке catch обычно представляет собой временную копию, созданную временем выполнения в процессе разворачивания стека. Хранение необработанного указателя создало бы висячую ссылку, как только блок catch завершится, и кадр стека будет уничтожен. Копируя исключение в кучу, std::current_exception() гарантирует, что объект существует независимо от стека потока, который его выбросил. Эта операция копирования также позволяет механизму стирания типа, позволяя std::exception_ptr управлять объектом через стертый делитель, сохраняя возможность повторно выбрасывать точный оригинальный тип позже.

Вопрос: Как std::promise предотвращает состояние гонки между set_value() и set_exception()?

Ответ.

Общая область состояния содержит атомарный флаг статуса, отслеживающий, удовлетворена ли обещание. Когда вызывается либо set_value(), либо set_exception(), реализация выполняет атомарную операцию сравнения и обмена, чтобы перейти от состояния "не удовлетворено" к "готово". Если состояние уже готово, операция выбрасывает std::future_error с promise_already_satisfied. Этот атомарный переход гарантирует, что поток-потребитель, наблюдающий за готовым состоянием, видит полностью построенное значение или исключение, предотвращая частичные чтения или записи во время одновременного доступа потока-продуцента и потока-потребителя.

Вопрос: Почему std::exception_ptr может пережить как std::promise, так и std::future, которые его создали?

Ответ.

std::exception_ptr использует внутренний подсчет ссылок на сам объект исключения, независимо от общей области состояния std::future/std::promise. Этот дизайн позволяет коду обработки исключений хранить ошибки в долгоживущих журналах или обработчиках ошибок после завершения асинхронной операции и уничтожения связанных объектов future/promise. Подсчет ссылок обеспечивает уничтожение объекта исключения только тогда, когда последний std::exception_ptr, ссылающийся на него, будет уничтожен, поддерживая такие случаи использования, как отсроченная отчетность об ошибках или агрегация исключений через несколько асинхронных операций.