重複の可能性:
マルチスレッド プログラムでの fork
fork() を使用し、マルチスレッドとして開発される可能性のあるアプリケーションがある場合、この種のアプリケーションを安全にプログラミングするために考慮すべき経験則/ガイドラインは何ですか?
重複の可能性:
マルチスレッド プログラムでの fork
fork() を使用し、マルチスレッドとして開発される可能性のあるアプリケーションがある場合、この種のアプリケーションを安全にプログラミングするために考慮すべき経験則/ガイドラインは何ですか?
さまざまなインターネット記事 ( http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them、fork in multi-threaded program )によると、基本的な経験則は次のとおりです。
(メイン) Process[0] モノスレッド --> fork() --> (子) Process[1] マルチスレッド: OK! Process[1]
がクラッシュしたり、メモリをいじったりしても、 Process[0]のアドレス空間には触れません(共有 R/W メモリを使用しない限り... ただし、これは別のトピックです)。Linux では、デフォルトでfork()edメモリはすべてCopy On Writeです。Process [0]がモノスレッド化されている場合、 fork()を呼び出すと、考えられるすべての相互排除プリミティブは通常、ロック解除された状態になります。
(メイン) Process[0] マルチスレッド --> fork() --> (子) Process[1] モノ/マルチスレッド:悪い!
マルチスレッド プロセスをfork()すると、ミューテックスや他の多くのスレッド同期プリミティブは、Process[1] で未定義の状態になる可能性があります。pthread_atfork()で回避できますが、ライブラリを使用する場合は、サイコロを振って幸運を祈るのもよいでしょう。一般に、ライブラリの実装の詳細を知らない (知りたくない) ためです。
マルチスレッド プロセスへのfork()の利点は、(メイン) からfork()するプロセスの安定性を気にすることなく、(子プロセスで) データをより迅速に操作/読み取り/集約できることです。これは、メイン プロセスに大量のメモリのデータセットがあり、別のプロセス (子プロセス) でデータを安全に処理するために複製/リロードしたくない場合に便利です。このようにして、元のプロセスは安定しており、データの集約/操作プロセス ( fork()ed ) から独立しています。
もちろん、これは元のプロセスがマルチスレッド方式で開発された場合よりも一般的に遅くなることを意味します。しかし、繰り返しますが、これは安定性を高めるために支払う代償です。
メイン プロセスがマルチスレッドの場合は、fork()の使用を控えてください。それを安定して実装するのは、適切な混乱になるでしょう。
乾杯
Linux では、スレッドはプロセスの観点から実装されます。言い換えれば、スレッドはfork()
、完全にコピーオンライトのメモリではなく、ほとんどが共有メモリを備えた単なるスレッドです。これが意味することfork()
は、スレッド (メインまたはその他) で使用すると、すべてのスレッドの共有メモリ空間全体と、呼び出し元のスレッドのスレッド固有のストレージをコピーすることになるということですfork()
。
これはすべて良いことのように聞こえますが、これが起こるか、うまくいくかということを意味するものではありません。プロセスのクローンを作成する場合は、他のスレッドを開始する前にフォークを実行してから、読み取り専用の仮想メモリを使用して、フォークされたプロセスを現在のメモリ値で最新の状態に保ちます。
したがって、うまくいくかもしれませんが、テストすることをお勧めし、最初に別の方法を見つけようとします. そして、多くのことに備えてください:
Segmentation fault