**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("Worker failed");
    } catch(...) {
        prom.set_exception(std::current_exception());
    }
}).detach();

try {
    int val = fut.get(); // 再スローされる runtime_error
} catch(const std::exception& e) {
    // 運ばれた例外を処理する
}

生活の中の状況

コンテキスト。

分散コンピューティングフレームワークは、GPUOutOfMemory または CorruptInputData 例外によって失敗する可能性のある画像セグメンテーションタスクを処理するワーカースレッドを必要としました。メインスレッドは、フォールバックのCPU処理やデータ再送信をトリガーするために、これらの特定の例外を受け取る必要がありました。

問題の説明。

最初の試みは手動で std::exception_ptr を使用しましたが、例外がメインスレッドのエラーキューによってまだ参照されている間に破棄されるライフタイムバグに苦しみました。開発者はまた、多様な例外タイプをポリモーフィックストレージ中にスライシングやオブジェクトスライシングなしで単一の結果コンテナに格納するのに苦労しました。

解決策 1: 型付き例外キュー。

チームは、各例外タイプのために別々のキューをテンプレートを使用して維持することを検討しました。これにより型安全性が提供されましたが、共通のキューでの型消去には std::any が必要になり、かなりのオーバーヘッドと複雑さが生じました。また、消費者スレッド内で try-catch ブロックを自然に使用して例外をキャッチする能力が損なわれました。

解決策 2: 仮想例外ホルダー。

彼らは、テンプレート化された派生クラスを std::unique_ptr<ExceptionBase> に保存する抽象の ExceptionBase クラスを実装しました。これによりポリモーフィックストレージは可能になりましたが、スレッド間での共有所有権を維持するために手動のクローンロジックが必要であり、再スロー時に仮想ディスパッチのオーバーヘッドが発生しました。カスタム参照カウントはエラーが発生しやすく、例外安全にするのが難しいものでした。

選択した解決策とその理由。

チームは std::packaged_task を std::future と共に採用しました。これは内部で std::promise/std::exception_ptr メカニズムを使用しています。これにより、標準ライブラリが例外のキャプチャと共有状態のライフタイムを自動的に処理するため、カスタムの型消去コードが不要になりました。この選択は、ゼロ維持の例外安全性の必要性と、カスタムベースクラスなしで標準の例外処理パターンをサポートする要件によって推進されました。

結果。

システムは、積極的なスレッドプールのサイズ変更中でもメモリリークなしで特定の例外タイプをスレッド境界を越えて成功裏に伝播させました。メインスレッドは、未知のエラーに対して std::exception にデフォルトしながら、特に GPUOutOfMemory をキャッチすることができ、エラーハンドリングロジックとスレッドの同期の間のクリーンな分離を維持しました。

候補者が見逃しがちなこと

質問: なぜ std::current_exception() は例外オブジェクトをコピーし、既存の例外へのポインタを保存しないのか？

回答。

キャッチブロック内の例外オブジェクトは通常、スタックの巻き戻り中にランタイムによって作成された一時的なコピーです。生のポインタを保存すると、キャッチブロックが終了し、スタックフレームが破棄されるとダングリング参照が発生します。例外をヒープにコピーすることによって、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 が破棄されるまで破棄されないことが保証され、遅延エラー報告や複数の非同期操作にわたる例外の集約などのユースケースをサポートします。