通常、マルチスレッド プログラムは非決定論的であると言われています。つまり、クラッシュした場合、その状態を引き起こしたエラーを再現することはほぼ不可能です。次にどのスレッドが実行されるか、またいつ再プリエンプトされるかはまったくわかりません。
もちろん、これは OS のスレッド スケジューリング アルゴリズムと関係しており、次にどのスレッドが実行されるか、またそれが実際にどれくらい実行されるかがわからないという事実に関係しています。プログラムの実行順序も役割を果たします。
しかし、スレッドのスケジューリングに使用されるアルゴリズムがあり、どのスレッドがいつ実行されているかを知ることができれば、マルチスレッド プログラムは「決定論的」になり、クラッシュを再現できるようになるでしょうか?
アルゴリズムを知っていても、実際に何がいつ起こるかを予測することはできません。プログラムまたはスレッドの実行で発生するあらゆる種類の遅延は、使用可能なメモリ、スワッピング、着信割り込み、その他のビジー タスクなどの環境条件に依存します。
マルチスレッド プログラムを順次実行にマップし、スレッド自体が決定論的に動作する場合、プログラム全体が決定論的になり、「同時実行性」の問題が再現可能になります。もちろん、その時点で、それらは並行性の問題ではなくなります。
詳細を知りたい場合は、http://en.wikipedia.org/wiki/Process_calculusを非常に興味深いものとして読んでください。
私の意見は次のとおりです。技術的にはいいえ（しかし数学的にははい）。決定論的なスレッド化アルゴリズムを作成することはできますが、非決定論的であると処理できる十分な時間が経過した後、アプリケーションの状態を予測することは非常に困難です。
各スレッドへの仮想サイクルの割り当てが完全に決定論的なプロセスを介して行われる仮想マルチスレッドマシンでプログラムを実行することは可能であり、おそらく疑似乱数ジェネレーターを使用します (各プログラムの前に定数をシードすることができます)。走る）。別の、おそらくもっと興味深い可能性は、「スプラッタ」モード (スレッドが触れるほとんどすべての変数がその値を他のスレッドに「不明」にする) と「クリーンアップ」モード (他のスレッドに対して「不明」になる) で実行中のスレッドを交互に実行する仮想マシンを持つことです。既知のオペランドを使用した操作の結果は、他のスレッドに表示され、認識されます)。この状況はおそらくハードウェア シミュレーションに似ていると思います: すべてのゲートの出力が「不明」と見なされる場合 最小伝播時間と最大伝播時間の間で、シミュレーションは機能します。これは、設計が堅牢であることを示していますが、そのようなシミュレーションで機能するように構築できなかった多くの有用な設計があります (状態は本質的に、有効な組み合わせですが、どの組み合わせかは保証できません)。それでも、多くのプログラムの大部分は、「スプラッタ モード」の VM でも正しく動作するように記述できるため、興味深い調査手段になる可能性があります。
ある程度予測可能な方法で競合状態を作成しようとする (開発中の) ツールがいくつかありますが、これは前向きなテストに関するものであり、「実際のバグ」を再構築することに関するものではありません。
チェスがその例です。
マルチスレッド プログラムでの多くのクラッシュは、マルチスレッド自体 (または関連するリソースの競合) とは何の関係もありません。
通常、マルチスレッド プログラムは非決定論的であると言われています。つまり、クラッシュした場合、その状態を引き起こしたエラーを再現することはほぼ不可能です。
確かにマルチスレッド プログラムは非決定論的ですが、ユーザー入力、メッセージ ポンプ、マウス/キーボードの処理、および他の多くの要因を考慮すると、シングルスレッド プログラムもそうです。通常、マルチスレッド プログラムではエラーの再現がより困難になりますが、決して不可能ではありません。なんらかの理由で、プログラムの実行は完全にランダムではなく、ある種の再現性があります (ただし、予測可能性はありません)。通常、アプリでマルチスレッドのバグをかなり迅速に再現できますが、アプリには多くの詳細なログが記録されます。エンドユーザーの行動。
余談ですが、クラッシュが発生している場合は、コール スタック情報を含むクラッシュ ログも取得できませんか? これは、デバッグ プロセスに大いに役立ちます。