0

メイン プロセスを別のスレッドに送信pthread_cancelし、このスレッドは で条件が発生するのを待っていますcond_wait(&condition)。pthread_cancel彼らは言っています：遅延キャンセル機能は、スレッドが次にキャンセルポイントである関数を呼び出すまでキャンセルが遅延されることを意味します。しかし、多くの場合、それらの機能はブロック機能です。次に、私の質問は、そのスレッドがブロック解除された後にのみスレッドがキャンセルされることです (私の例では、ブロードキャストまたはシグナルによって) または、現在キャンセルポイントでブロックされていることがわかり、スレッドがキャンセルされますか?

4

2 に答える 2

1

私は に慣れていませんが、通常使用される?cond_waitとは別のライブラリからのものだと思います。pthread_cond_wait

しかし、はい、スレッドが a でブロックされてpthread_cond_waitからキャンセルされた場合、スレッドは起動され、そのミューテックスを再取得してからキャンセルされます。

したがって、条件でブロックされているスレッドをキャンセルする際に留意すべき重要な点が 2 つあります。

  1. を呼び出す前に、mutex がロック解除されている (または将来的にロック解除される) ことを確認してくださいpthread_cancel。たとえば、スレッド A が条件を待機していて、スレッド B が条件ミューテックスをロックし、条件ミューテックスをロック解除する前にpthread_canceland を呼び出すと、pthread_joinデッドロックが発生します。

  2. クリーンアップ ハンドラ (「参考文献」を参照pthread_cleanup_push) をインストールして、呼び出す前に条件ミューテックスのロックを解除します。pthread_cond_waitそうしないと、スレッドがキャンセルされ、ミューテックスがロックされたままになります。

ただし、pthread 条件変数の実装にはいくつかのバグがあることに注意してください。最新の glibc を使用してください。

于 2013-03-26T17:50:04.533 に答える
0

cond_wait の代わりに pthread_cond_wait を使用することもできます。

pthread_cond_wait を使用し、これに基づいて man pthread_cond_wait(3) を使用する場合

条件待機 (時間指定されているかどうかに関係なく) はキャンセル ポイントです。スレッドのキャンセル可能性有効状態が PTHREAD_CANCEL_DEFERRED に設定されている場合、条件待機中にキャンセル要求に応答することの副作用は、最初のキャンセル クリーンアップ ハンドラーを呼び出す前にミューテックスが (事実上) 再取得されることです。その効果は、あたかもスレッドがブロックされていないかのようであり、pthread_cond_timedwait() または pthread_cond_wait() への呼び出しから戻る時点までは実行を許可されますが、その時点でキャンセル要求に気づき、pthread_cond_timedwait() の呼び出し元に戻る代わりにまたは pthread_cond_wait() は、スレッドのキャンセル アクティビティを開始します。これには、キャンセル クリーンアップ ハンドラーの呼び出しが含まれます。

現在ブロックされていても、スレッドは pthread_cond_wait でキャンセルされるようです

または、pthread_setcanceltype でキャンセル タイプを ASYNCHRONOUS に設定することもできます。以下のコメントを参照してください

しかし、ほとんどの場合と同様に、確実に知るための最良の方法は、テスト コードで試してみることです。

于 2013-03-26T17:35:29.300 に答える