12

背景:

サードパーティのハードウェアとクローズド ソース ドライバーに依存するアプリケーションがあります。現在、ドライバーにはバグがあり、デバイスがランダムな時間後に応答を停止します。これは、ドライバー内の明らかなデッドロックが原因であり、24 時間 365 日常時オンの非常に目に見える環境にあるアプリケーションの適切な機能を中断します。

私が見つけたのは、GDB をプロセスにアタッチし、すぐにプロセスから GDB をデタッチすると、デバイスが機能を再開することです。これは、ドライバー自体にスレッド ロックの問題があることを示す最初の兆候でした。デッドロックにつながるある種の競合状態があります。GDB をアタッチすると、明らかにスレッドの再シャッフルが発生し、おそらくスレッドが待機状態から抜け出し、スレッドの状態が再評価され、デッドロックが解消されました。

質問：

私の質問は次のとおりです。アプリケーションがプログラム内のすべてのスレッドをトリガーして待機状態を中断するためのクリーンな待機はありますか? (少なくとも私の実装では)確実に機能することの 1 つは、SIGSTOP を送信し、その後すぐに別のプロセス (つまり、bash から) から SIGCONT を送信することです。

kill -19 `cat /var/run/mypidfile` ; kill -18 `cat /var/run/mypidfile`

これにより、プロセス内で偽のウェイクアップがトリガーされ、すべてが元に戻ります。

プロセス内のすべてのスレッドの誤ったウェイクアップをトリガーするインテリジェントな方法があることを願っています。考えpthread_cond_broadcast(...)てみてください。ただし、待機中の実際の状態変数にアクセスする必要はありません。

killこれは可能ですか、それとも私の唯一のアプローチのようなプログラムに依存していますか?

4

1 に答える 1

5

あなたが今それをしている方法は、おそらく最も正確で最も単純です。カーネルには「特定のプロセスで待機しているすべてのfutexをウェイクアップする」操作はありません。これは、これをより直接的に実現するために必要な操作です。

ウェイク失敗の「デッドロック」が発生しpthread_cond_waitているが、シグナルで中断するとデッドロックが解除される場合、バグはアプリケーションに存在しない可能性があることに注意してください。実際には、pthread条件変数の実装に含まれている必要があります。glibcは、条件変数の実装に未修正のバグがあることを知っています。http://sourceware.org/bugzilla/show_bug.cgi?id=13165および関連するバグレポートを参照してください。しかし、あなたは新しいものを見つけたかもしれません。なぜなら、既存の既知のものは、信号でfutex待機から抜け出すことによって修正できるとは思わないからです。このバグをglibcバグトラッカーに報告できれば、非常に役立ちます。

于 2012-12-26T23:22:33.473 に答える