Linuxアプリケーション内で偽起動を起動するにはどうすればよいですか？

Question

いくつかの背景：

私はサードパーティ製のハードウェアとクローズドソースのドライバに依存しているアプリケーションがあります。現在、ドライバにはバグがあり、ランダムな時間が経過するとデバイスが応答を停止します。これは、ドライバ内で明らかなデッドロックが原因で発生し、アプリケーションが正しく機能するのを妨げています。これは常時接続の24時間365日の非常に目に見える環境です。

私が発見したのは、GDBをプロセスに接続し、プロセスからGDBをすぐに切り離すと、デバイスが機能を再開するということです。これは、ドライバ自体にスレッドロックの問題があったという私の最初の兆候でした。デッドロックにつながる何らかの競合状態があります。 GDBをアタッチすると、明らかにスレッドの再編成が発生し、待機状態から外して状態を再評価し、デッドロックを解除する可能性がありました。

質問：

私の質問は、単にこれです：彼らの待機状態を中断するプログラム内のすべてのスレッドをトリガするアプリケーションのためのクリーンな待ち時間はありますか？確かに（少なくとも私の実装に）働くことの一つは、他のプロセスからSIGCONTによりSIGSTOPは直後に送信することである（つまり、bashのから）：これは、プロセスとすべてのものの中スプリアスウェイクアップをトリガ

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

人生に戻ってくる。

私のプロセス内のすべてのスレッドの偽の起床を引き起こすインテリジェントな方法があることを期待しています。 pthread_cond_broadcast(...)と考えてください。ただし、実際の条件変数にアクセスすることはできません。

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

Answer 1

あなたが今やっているやり方はおそらく最も正確で簡単です。カーネル内の "特定のプロセスにすべての待機中のfutexを"起きさせることはありません。これは、これをより直接的に達成するために必要なものです。

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