stdでのRAIIの問題の解決::スレッド：cancel_tokenをpthread_cancelおよびboostの代替として::スレッド::割り込み

この記事では、std :: threadの問題に対処し、「pthread_cancel、boolean flagまたはboost :: thread :: interrupt？」というトピックに関する古代の議論を同時に解決します。

問題

C ++ 11で追加されたstd :: threadクラスには、1つの不快な機能があります。これは、 RAIIイディオム（Resource Acquisition Is Initialization）に対応していません。 標準からの抜粋：

30.3.1.3スレッドデストラクタ
〜スレッド（）;
joinable（）の場合はterminate（） 、それ以外の場合は効果はありません。

このようなデストラクタで私たちを脅かすものは何ですか？ プログラマは、 std::threadオブジェクトを破棄する際に非常に注意する必要があります。

 void dangerous_thread() { std::thread t([] { do_something(); }); do_another_thing(); // may throw - can cause termination! t.join(); } 

do_another_thing関数から例外がスローされた場合、 std::thread destructorはstd::terminate呼び出してプログラム全体をstd::terminate 。 これで何ができますか？ std::thread周りにRAIIラッパーを書いてみて、この試みが私たちをどこに連れて行くか見てみましょう。

RAIIをstdに追加::スレッド

 class thread_wrapper { public: // Constructors ~thread_wrapper() { reset(); } void reset() { if (joinable()) { // ??? } } // Other methods private: std::thread _impl; }; 

thread_wrapperは、 std::threadインターフェースをコピーし、別の追加の関数resetを実装します。 この関数は、スレッドを結合不可能な状態にする必要があります。 デストラクタはこの関数を呼び出すため、その後_impl std::terminateを呼び出さず_impl折りたたみstd::terminate 。

_implを非結合状態にするために、 resetはdetachまたはjoin 2つのオプションがあります。 detachの問題は、スレッドが引き続き実行され、混乱を引き起こし、RAIIイディオムに違反することです。 だから私たちの選択はjoinです：

 thread_wrapper::reset() { if (joinable()) join(); } 

深刻な問題

残念ながら、 thread_wrapperこのような実装は、通常のstd::threadよりも優れていstd::thread 。 なんで？ 次の使用例を見てみましょう。

 void use_thread() { std::atomic<bool> alive{true}; thread_wrapper t([&alive] { while(alive) do_something(); }); do_another_thing(); alive = false; } 

do_another_thingから例外がdo_another_thingれた場合、異常終了は発生しません。 ただし、 aliveがfalseになることはなく、スレッドは終了しないため、 thread_wrapperデストラクターからのjoin呼び出しは永久にthread_wrapper ます 。

問題は、 thread_wrapperオブジェクトthread_wrapper 、実行中の関数に影響を与えて完了を「求める」方法thread_wrapperないことです。 do_something関数では、実行スレッドが条件変数またはオペレーティングシステムのブロック呼び出しで「スリープ」状態になる可能性があるため、状況はさらに複雑になります。

したがって、 std::threadデストラクタで問題を解決するには、より深刻な問題を解決する必要があります。

長い関数の実行を中断する方法、特にこの関数で実行のスレッドが条件変数またはOSのブロッキング呼び出しで「スリープ」できる場合はどうすればよいですか？

この問題の特殊なケースは、実行スレッド全体の中断です。 実行スレッドに割り込むための3つの既存のメソッドを見てみましょう： pthread_cancel 、 boost::thread::interruptおよびbooleanフラグ。

既存のソリューション

pthread_cancel

選択したスレッドに割り込み要求を送信します。 POSIX仕様には、割り込み可能な関数の特別なリスト （ read 、 writeなど）が含まれています。 いくつかのスレッドに対してpthread_cancelを呼び出した後、このスレッドのこれらの関数は特別なタイプの例外をスローし始めます。 この例外は無視できません。このような例外をキャッチしたcatchブロックはさらに例外をスローする必要があるため、この例外はスレッドスタックを完全に巻き戻して終了します。 スレッドは、 pthread_setcancelstate関数を使用して、呼び出しの中断を一時的に防ぐことができます（可能な使用法の1つは、デストラクタ、ロギング関数などからの例外を回避するためです）。

長所：

• 条件変数の待機を中止できます
• OSブロッキング呼び出しを中断できます
• 割り込み要求を無視するのが難しい

短所：

• 大きな移植性の問題： Windowsでのpthread_cancelの明らかな欠如に加えて、一部のlibc実装（ Androidで使用されるbionicなど）でも欠落しています
• std::condition_variable::wait C ++ 14以降の標準でstd::condition_variable::waitするstd::condition_variable::wait問題
• 割り込み可能な関数を使用するCコードで問題を引き起こす可能性があります（特殊効果のリスト：リソースリーク、ミューテックスが時間通りにロック解除されないなど）。
• デストラクタの割り込み関数には特別な注意が必要です（たとえば、 closeは割り込み関数です）
• 例外のない環境では使用できません
• 個々の機能またはタスクを中断するために使用することはできません。

std::condition_variable::wait問題は、C ++ 14 std::condition_variable::waitにnoexcept仕様が指定されているためにnoexceptます。 pthread_setcancelstateで割り込みを有効にすると、条件変数の待機を中断する機能が失われます。割り込みが許可されると、この特定の例外を「飲み込む」ことができないため、 noexcept仕様を満たすことができません。

ブースト::スレッド::割り込み

Boost.Threadライブラリは、 pthread_cancelにいくらか似たオプションのスレッド割り込みメカニズムを提供します。 実行のフローを中断するには、対応するboost::threadオブジェクトでinterruptメソッドを呼び出すだけで十分です。 boost::this_thread::interruption_point関数を使用して、現在のスレッドのステータスを確認できます。割り込みスレッドでは、この関数はタイプboost::thread_interrupted例外をスローします。 BOOST_NO_EXCEPTIONSを使用して例外の使用が禁止されている場合、 boost::this_thread::interruption_requestedを使用してステータスを確認できます。 Boost.Threadでは、 boost::condition_variable::wait待機を中断することもできます。 これを実装するには、スレッドローカルストレージと条件変数内の追加のミューテックスを使用します。

長所：

• 移植性
• boost::condition_variable::waitを中止できますboost::condition_variable::wait
• 例外なく環境で使用できます。

短所：

• Boost.Threadへのバインド-この割り込みメカニズムは、標準の条件変数またはスレッドでは使用できません
• condition_variable内に追加のmutexが必要condition_variable
• オーバーヘッド：各condition_variable::wait 2つの余分なロック/ロック解除ミューテックスを追加しcondition_variable::wait
• OSブロックコールを中断できません
• 個々の機能またはタスクを中断するために使用するのは問題です（コードで判断すると、これは例外を使用してのみ実行できます）
• 例外の哲学に対する軽微な違反-フローの中断は、プログラムのライフサイクルにおいて例外的な状況ではありません

ブールフラグ

StackOverflowでpthread_cancel （ 1、2、3、4 ）に関する質問を読んだ場合、最も一般的な回答の1つは「 pthread_cancel代わりにブールフラグを使用する」です。

例外のあるこの例でaliveアトミック変数は、ブールフラグです。

 void use_thread() { std::atomic<bool> alive{true}; thread_wrapper t([&alive] { while(alive) do_something(); }); do_another_thing(); // may throw alive = false; } 

長所：

• プラットフォームに依存しない
• ストリームのブレークポイントは明らかです

短所：

• コードの複製
• 分解が邪魔です-ブロック関数を書く簡単で効率的な方法はありません
• 条件付き変数の待機を中断しないでください（特に、ブール型フラグを使用してクラスの外にある場合）
• OSブロックコールを中断できません

キャンセルトークン

どうする ブールフラグを基にして、それに関連する問題の解決を始めましょう。 コードの重複？ すばらしい-ブールフラグを別のクラスにラップしましょう。 それをcancellation_tokenと呼びましょう。

 class cancellation_token { public: explicit operator bool() const { return !_cancelled; } void cancel() { _cancelled = true; } private: std::atomic<bool> _cancelled; }; 

thread_wrapperできます。

 class thread_wrapper { public: // Constructors ~thread_wrapper() { reset(); } void reset() { if (joinable()) { _token.cancel(); _impl.join(); } } // Other methods private: std::thread _impl; cancellation_token _token; }; 

さて、トークンへのリンクを別のスレッドで実行される関数に転送するだけです：

 template<class Function, class... Args> thread_wrapper(Function&& f, Args&&... args) { _impl = std::thread(f, args..., std::ref(_token)); } 

説明のためにthread_wrapperを書いているので、まだstd::forwardを使用することはできず、同時に、移動コンストラクターとswap関数で発生する問題を無視できます。

use_threadと例外をuse_threadた例を思い出してuse_thread 。

 void use_thread() { std::atomic<bool> alive{true}; thread_wrapper t([&alive] { while(alive) do_something(); }); do_another_thing(); alive = false; } 

cancel_tokenのサポートを追加するには、ラムダに正しい引数を追加しaliveを削除するだけです。

 void use_thread() { thread_wrapper t([] (cancellation_token& token) { while(token) do_something(); }); do_another_thing(); } 

いいね！ do_another_thingから例外がdo_another_thingれた場合でもdo_another_thingデストラクタthread_wrapperまだdo_another_thing cancellation_token::cancelを呼び出し、スレッドは実行を完了します。 さらに、cancel_tokenのブールフラグのコードを削除すると、この例ではコードの量が大幅に削減されました。

待機の中断

条件付き変数で待機するなど、ブロッキングコールを中断するようにトークンを教えるときです。 特定の割り込みメカニズムから抽象化するには、 cancellation_handlerインターフェイスが必要です。

 struct cancellation_handler { virtual void cancel() = 0; }; 

条件変数の待機を中止するハンドラーは次のようになります。

 class cv_handler : public cancellation_handler { public: cv_handler(std::condition_variable& condition, std::unique_lock<mutex>& lock) : _condition(condition), _lock(lock) { } virtual void cancel() { unique_lock l(_lock.get_mutex()); _condition.notify_all(); } private: std::condition_variable& _condition; std::unique_lock<mutex>& _lock; }; 

ここで、cancelation_tokenにcancel_handlerへのポインターを置き、cancelation_handler cancellation_handler::cancelからcancellation_handler::cancelを呼び出します。

 class cancellation_token { std::mutex _mutex; std::atomic<bool> _cancelled; cancellation_handler* _handler; public: explicit operator bool() const { return !_cancelled; } void cancel() { std::unique_lock<mutex> l(_mutex); if (_handler) _handler->cancel(); _cancelled = true; } void set_handler(cancellation_handler* handler) { std::unique_lock<mutex> l(_mutex); _handler = handler; } }; 

条件変数の待機の中断バージョンは、次のようになります。

 void cancellable_wait(std::condition_variable& cv, std::unique_lock<mutex>& l, cancellation_token& t) { cv_handler handler(cv, l); // implements cancel() t.set_handler(&handler); cv.wait(l); t.set_handler(nullptr); } 

注意！ 指定された実装は、例外とスレッドセーフの両方の観点から安全ではありません。 彼女はここで、anceration_handlerの動作メカニズムを説明するためにのみここにいます。 正しい実装へのリンクは、記事の最後にあります。

対応するcancellation_handler実装することにより、OSへのブロッキング呼び出しと他のライブラリからのブロッキング関数を中断するようにトークンに教えることができます（これらの関数が待機を中断するメカニズムを少なくとも持っている場合）。

再スレッドライブラリ

説明されているトークン、ハンドラー、およびスレッドは、オープンソースライブラリとして実装されています： https : //github.com/bo-on-software/rethread 、 ドキュメント （英語）、 テスト、およびベンチマーク 。

以下は、コードとライブラリに実装されているものとの主な違いのリストです。

• cancellation_tokenは、いくつかの実装を持つインターフェースです。 中断された関数は、 定数リンクによってcancelal_tokenを受け取ります
• トークンは一般的に使用される操作にミューテックスの代わりにアトミックを使用します
• スレッドのラッパーはrethread::threadと呼ばれrethread::thread

ライブラリにあるもの：

• トークン
• RAII互換ストリーム
• std::condition_variable互換性のある条件変数での割り込み可能な待機std::condition_variable
• poll待機の中断-これにより、多くのブロッキングPOSIX呼び出し（ read 、 writeなど）の中断バージョンを実装できます。

性能

測定は、Intel Core i7-3630QM @ 2.4GHzプロセッサを搭載したラップトップで実行されました。

以下は、再rethreadトークンベンチマークの結果です。
次の操作のパフォーマンスが測定されました。

• 状態の確認は、 cancellation_token::is_cancelled()関数（または同等のブール型へのコンテキスト変換cancellation_token::is_cancelled()を呼び出すことの代償です
• 中断された関数の呼び出しは、中断されたブロッキング関数のオーバーヘッドです。呼び出しの前にトークンにハンドラーを登録し、呼び出しの終了後に「登録解除」します
• standalone_cancellation_token 1つ作成します

Ubuntu 16.04

Windows 10

マイナスのオーバーヘッド

このような低い割り込みオーバーヘッドは、興味深い効果を生み出します。
状況によっては、割り込み関数は「通常の」アプローチよりも高速です。
トークンを使用しないコードでは、ブロック機能を永久にブロックすることはできません-その後、「正常な」アプリケーションの終了を達成することはできませんexit(1);ような異常。正常と見なすことはできません）。 永続的なブロックを回避し、ステータスを定期的に確認するには、タイムアウトが必要です。 たとえば、これ：

 while (alive) { _condition.wait_for(lock, std::chrono::milliseconds(100)); // ... } 

まず、このようなコードは、フラグを確認するために100ミリ秒ごとに起動します（タイムアウト値は増やすことができますが、「合理的な」アプリケーション終了時間によって上から制限されます）。

第二に、このコードはそのような無意味な覚醒がなくても最適ではありません。 事実は、 condition_variable::wait_for(...)の呼び出しはcondition_variable::wait_for(...)よりも効率がcondition_variable::wait(...)少なくとも、現在の時刻を取得し、ウェイクアップ時間を計算する必要があります。

このステートメントを証明するために、rethread_testingで2つの合成ベンチマークを作成し、マルチスレッドキューの2つの基本的な実装を比較しました。「通常」（タイムアウト付き）と割り込み（トークン付き）です。 プロセッサ時間は、キュー内の1つのオブジェクトの出現を待つために測定されました。

そのため、MSVS 2015では、割り込み可能なバージョンはタイムアウトのある「通常の」バージョンよりも1.4速く実行されます。 Ubuntu 16.04では、違いはそれほど顕著ではありませんが、中断されたバージョンは明らかに「通常の」バージョンよりも優れています。

おわりに

これが問題の唯一の可能な解決策ではありません。 最も魅力的な代替方法は、トークンをスレッドローカルストレージに配置し、中断時に例外をスローすることです。 動作はboost::thread::interruptに似ていboost::thread::interruptが、各条件変数に追加のmutexがなく、オーバーヘッドが大幅に少なくなります。 このアプローチの主な欠点は、既に述べた例外の哲学の違反とブレークポイントの非自明性です。

トークンを使用したアプローチの重要な利点は、フロー全体ではなく、個別のタスクを中断できることです。ライブラリに実装されているcancellation_token_sourceライブラリを使用すると、同時に複数のタスクを中断できます。

ほとんどすべてのウィッシュリストをライブラリに実装しました。 私の意見では、ファイルやソケットを操作するようなブロックシステムコールとの統合が不足しています。 read 、 write 、 connect 、 acceptなどの割り込み可能なバージョンを書き込みます。 難しいことではありません。主な問題は、トークンを標準のiostreamに貼り付けたがらないことと、一般に受け入れられている代替手段がないことです。