std::threadのデストラクタは、その内部状態について暗黙のチェックを行います。スレッドがjoinableのまま—つまり、まだジョインされていないか切り離されていないアクティブな実行スレッドを表す場合—デストラクタはstd::terminateを呼び出し、プログラムが潜在的に問題のあるスレッドで続行するのを防ぎます。この設計は明示的なライフサイクル管理を強制しますが、例外の安全性や早期リターンのパスにとって重大な負担を生じます。
std::jthreadは、C++20で導入され、このリスクを排除し、協調的なキャンセリングと同期をそのRAII設計内にカプセル化します。デストラクタは最初に内部のstd::stop_sourceを通じてキャンセルを通知し、次に自動的に**join()**を呼び出し、スレッドの実行が完了するまでブロックします。これにより、オブジェクトが破棄される前にスレッドが優雅に終了することが保証され、手動での介入なしに偶発的終了の可能性が取り除かれます。
// 危険: std::thread void risky_task() { std::thread t([]{ /* バックグラウンド処理 */ }); if (config_error) return; // std::terminate()がここで呼び出されます！ t.join(); } // 安全: std::jthread void safe_task() { std::jthread t([](std::stop_token st) { while (!st.stop_requested()) { /* 作業 */ } }); if (config_error) return; // 安全: デストラクタが停止を要求し、ジョインします }
マーケットデータフィーダースレッドを生成して受信したクォートを処理する高頻度取引アプリケーションを考えてみてください。初期化中にネットワーク構成が無効であることが判明した場合、関数は早期に戻り、std::threadオブジェクトを破棄して**join()**を呼び出す前に戻ります。このシナリオは、スレッド生成後にリソース取得が失敗する可能性がある非同期I/Oバウンドアプリケーションで頻繁に発生し、生産環境で即時クラッシュを引き起こします。
検討されたアプローチの1つは、スレッドを手動のtry-catchブロックでラップして、すべてのリターンパスや例外ハンドラの前にjoin()が実行されるようにすることでした。明示的ではありましたが、これはもろいことが判明しました。新しい終了ポイントやリファクタリングを追加すると、ジョインロジックが省略される回帰が頻繁に発生し、エラー回復中に不定期にstd::terminateが呼び出されました。
別の評価された解決策は、スレッド参照を保存し、そのデストラクタでジョインするカスタムScopeGuardクラスを含むことでした。これは安全ロジックをカプセル化していたものの、すでにライブラリに標準化された機能を複製し、複数のモジュールでボイラープレートコードを維持する必要があり、技術的負債とレビューのオーバーヘッドを増加させました。
最終的に、チームはC++20への移行に伴いstd::jthreadを採用しました。std::threadを置き換えることにより、デストラクタは自動的にstd::stop_tokenを介してキャンセルを通知し、手動の同期ブロックなしでスレッドの完了を待機しました。これにより、例外や早期リターンによるスタックのバイイング中のクリーンアップの確保の負担が取り除かれ、安全で保守性の高いコードベースが実現しました。
なぜstd::threadでjoin()を2回呼び出すと未定義の動作を引き起こすのか、またstd::jthreadはこれをどのようにプログラムで防ぐのか？
std::threadオブジェクトは、実行スレッドへの有効なハンドルを持っているかどうかを追跡します。**join()**が呼び出されると、スレッドは非ジョイン可能になりますが、標準ではその後の呼び出しが安全にこの状態をチェックすることを義務付けていません。**join()**を再度呼び出すことは、スレッドがジョイン可能であることの前提条件に違反し、通常はクラッシュ、デッドロック、またはリソースリークとして現れる未定義の動作を引き起こします。
std::jthreadは、強力な内部状態追跡により、**join()を冪等に保つことによってこれを防ぎます。デストラクタはスレッドがジョイン可能な場合にのみjoin()**を呼び出し、その後の明示的な呼び出しは何もせず、スマートポインターのリセット操作の動作を真似て、偶発的な二重ジョインエラーを防ぎます。
std::jthreadのstd::stop_tokenは、協調的なキャンセリングをどのように可能にし、非同期スレッド中断のプリミティブよりもなぜ優れているのか？**
std::jthreadは各スレッドにstd::stop_sourceをペアリングし、スレッドのエントリ関数にstd::stop_tokenを渡します。ワーカーは定期的にstop_requested()をチェックしてループをクリーンに終了し、不変条件を維持し、ミューテックスを解放します。これは、スレッド中断がpthread_cancelやTerminateThreadなどのプラットフォーム固有の呼び出しを必要とし、中断命令の途中で実行を強制終了させるstd::threadとは大きく対照的です。これは、共有リソースが破損したりロックされた状態になる可能性があります。
std::jthreadが別のオブジェクトに移動されると、キャンセリングシグナルはどうなり、実行中のスレッドはその移動を認識しますか？**
std::jthreadが移動されると、ソースオブジェクトは基底スレッドハンドルとstd::stop_sourceの所有権を放棄し、空で非ジョイン可能になります。宛先オブジェクトはスレッドの制御を引き継ぎます。重要なことに、ワーカー関数に渡されるstd::stop_tokenは、std::stop_sourceによって管理されるstop_stateを参照し続けているため、有効です。元のスレッドは、新しいjthreadオブジェクトの所有権の下で実行を続け、新しいハンドルを介してのキャンセル要求は元のワーカーにシームレスに届きます。