25

プログラムで fork と threading を混在させると、特にロック、パイプ、ファイル記述子などの共有リソースを扱う場合に、不思議な動作が発生することが多く、非常に問題になる可能性があると聞いたことがあります。しかし、危険が正確に何であり、いつ発生する可能性があるかを完全に理解することはできません. この分野の専門知識を持つ人が、そのような環境でプログラミングする際に落とし穴とは何か、注意が必要なことをもう少し詳しく説明してくれると助かります。

たとえば、さまざまなリソースからデータを収集するサーバーを作成したい場合、私が考えた 1 つの解決策は、サーバーに一連のスレッドを生成させ、各スレッドが別のプログラムを呼び出して実際の作業を実行し、パイプを開くことです。子からデータを取得します。これらのスレッドはそれぞれ独自の作業に応答し、双方向のデータ交換はありません。データが収集されると、メイン スレッドにはキューがあり、これらのワーカー スレッドは結果をキューに入れるだけです。このソリューションで何が問題になる可能性がありますか?

私の例のシナリオに「答える」だけで答えを狭めないでください。例に関係なく、クリーンなデザインを提供するのに役立つ提案、代替ソリューション、または経験は素晴らしいでしょう! ありがとう!

4

2 に答える 2

20

いくつかのスレッドを実行している場合のフォークの問題は、フォークがそれを呼び出した 1 つのスレッドの CPU 状態のみをコピーすることです。他のすべてのスレッドが、どこにいても即座に死んだかのようです。

その結果、ロックが解放されず、共有データ (malloc ヒープなど) が破損する可能性があります。

pthread はpthread_atfork関数を提供します。理論的には、フォークする前にプログラム内のすべてのロックを取得し、後で解放し、おそらくロックを解除することができます。もちろん、他のスレッドのスタックは解放されません。

于 2009-08-05T20:33:21.370 に答える
0

それは本当にとても簡単です。複数のスレッドとプロセスに関する問題は、常に共有データから発生します。共有データがない場合、問題が発生する可能性はありません。

あなたの例では、共有データはメインスレッドが所有するキューです-潜在的な競合または競合状態がここで発生します。これらの問題を「解決」するための一般的な方法には、ロック スキームが含まれます。ワーカー スレッドはデータを挿入する前にキューをロックし、メイン スレッドは削除する前にキューをロックします。

于 2009-08-05T20:22:34.230 に答える