問題タブ [deadlock]

デッドロックは見つけるのが難しく、取り除くのが非常に困難です。

コード内のデッドロックのエラー ソースを見つけるにはどうすればよいですか? 「デッドロックパターン」はありますか?

私の特別なケースでは、データベースを扱いますが、この質問はすべてのデッドロックに対して未解決です。

DirectShow アプリケーションを開発しています。デッドロックの問題が発生しました。この問題は、スレッドから呼び出されたコールバック関数でロックを取得したことが原因のようです。これは、MSDN フォーラムで質問したクエストです。

http://social.msdn.microsoft.com/Forums/en-US/windowsdirectshowdevelopment/thread/f9430f17-6274-45fc-abd1-11ef14ef4c6a

ここで、そのスレッドでロックを取得することを避ける必要があります。しかし、問題は、オーディオを別のスレッドに出力する必要があることです。どうすればロックせずにデータを別のスレッドに入れることができますか?

win32 sdk の PostMessage を使用して別のスレッドにデータを投稿できると言う人がいます。ただし、メッセージを取得するには、Windows プログラムを実行する必要があります。私のプログラムは Python C++ 拡張モジュールです。メッセージをプルするループを追加するのは非常に難しい場合があります。したがって、ロックせずにスレッド間でデータを渡す別の方法を考えています。（実際には...プロデューサースレッドはロックできませんが、コンシューマースレッドはロックできます。）

ロックするかしないか、それが問題だ。

では、問題はどのように行うかです。

ありがとう。

- - - 編集 - - -

デッドロックが発生した理由はわかっていると思いますが、それは DirectShow の問題ではない可能性があります。

メインスレッドは Python が所有しており、stop を呼び出します。つまり、GIL を保持します。そしてスレッドリターンでDirectShowのコールバック待ちを停止。ただし、コールバックは GIL を取得します。

このように見えます

メイン(GILを保持) -> 停止(コールバックを待機) -> コールバック(GILを待機) -> GIL(メインスレッドで保持)

くそ！そのため、マルチスレッドはあまり好きではありません。何はともあれ、助けてくれてありがとう。

次のSQLステートメントは、mssqlserver2000サーバーでデッドロックを生成することがあります

何らかの理由で、削除がブロックステータスになり、終了しません（？）これによってブロックされていることがわかった他の唯一のプロセスは、インデックスを再作成するために週末に実行されるメンテナンスプランであるため、何ができるかについてのアイデアがありません。問題を引き起こしている。

これは、削除によって生成されたロックです...

問題の根本に到達する方法について誰かが何か指針を持っていますか？テーブルtb_intervaloServicoは、削除と選択で呼び出されているため、ブロッキングのルートであると思われますが、動作を再現できません。

私は実際にMPIプログラムを書いています。これは基本的なクライアント/サーバー パターンです。サーバーには、計算する一連の作業があります。クライアントは、この大きなセットのサブセットを取得します。各クライアントは、いくつかのスレッドを使用してサブセットを計算します。サーバーに別のサブセットを要求する前に、すべてのスレッドが終了していることを確認する必要があります。

クライアントは、マスター (通信用) と複数のワーカーの複数のスレッドに分割されます。

ここで、デッドロックが発生するはずの実際のコードを示します。読みやすくするために、MPI 呼び出しを削除しました。ここで何が間違っているのか本当にわかりません。

デッドロックに直面しています。コード構造は次のようになります。

しかし、同じコードを使用して、UpdateControl メソッドを次のように変更しました。

これはうまくいっています。何が問題ですか？

Windowsアプリケーションでpthreadを使用しています。プログラムがデッドロックしていることに気づきました。簡単に調べたところ、次のことが発生したことがわかりました。

スレッド1がスレッド2を生成しました。スレッド2がスレッド3を生成しました。スレッド2は、ロック解除されていないスレッド3からのミューテックスを待機していました。

そこで、gdbでデバッグし、3番目のスレッドをバックトレースすると次のようになりました。

どういうわけか、WindowsのCreateThread関数でスタック、デッドロックしました！明らかに、コードの実行を開始することさえできなかったとき、ミューテックスのロックを解除することはできませんでした。それでも、明らかにここでスタックしているという事実にもかかわらず、pthread_createはゼロ（成功）を返しました。

これを特に奇妙なものにしているのは、Linux上の同じアプリケーションにそのような問題がないことです。作成プロセス中にスレッドがハングする（！？）が、正しく作成されたかのように正常に戻る原因は、いったい何でしょうか。

編集：コードのリクエストに応じて、ここにいくつかのコードがあります（簡略化されています）：

スレッドの作成：

b_thread_activeが設定されるまで待機することに注意してください。したがって、何らかの形でb_thread_activeが設定されているため、呼び出されるスレッドは何かを実行する必要があります...

...これがlookahead_thread関数です：

lookahead_slicetype_decide（h）; スレッドが行うことです。

ミューテックス、synch_frame_list_get_size：

スレッド2のバックトレース：

デッドロック回復を提供するORMツールを知っていますか？デッドロックは悪いことだと私は知っていますが、適切な量の負荷が与えられると、どのシステムでもデッドロックに悩まされることがあります。SQL Serverでは、デッドロックメッセージに「トランザクションを再実行してください」と表示されているため、デッドロックステートメントの再実行がORMの望ましい機能であると思われます。

適切に理解できないコードが少しあります。問題は、プログラムがマルチスレッド化されており、同期する必要があるコードが少しあるため、次のように記述したことです。

私が抱えている問題は、ある時点ですべてのスレッドがスリープしているように見えることです-誰かが理由を教えてもらえますか? プログラムはほとんど CPU を消費せずに無限に実行され続けますが、作業は行われません。私はエラーがほとんど（開発者の場合-常に）モニターの前0.5mにあることを知っています-しかし、私はそれを自分で理解することはできません...おそらく数分で;）

誰かが私にそれを説明してもらえますか - 前もって感謝します。