From 2008精選

鉄則3: マルチスレッドのプログラムでのforkはやめよう
準則3：多線程程序里不準使用fork

マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している狀態(tài)」でfork

何が起きるか
能引起什么問題呢?

実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。
那看看實例吧.一執(zhí)行下面的代碼,在子進程的執(zhí)行開始處調用doit()時,發(fā)生死鎖的機率會很高.

 1void* doit(void*) {
 2
 3    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
 4
 5    pthread_mutex_lock(&mutex);
 6
 7    struct timespec ts = {10, 0}; nanosleep(&ts, 0); // 10秒寢る
 8                                                     // 睡10秒
 9
10    pthread_mutex_unlock(&mutex);
11
12    return 0;
13
14}
15
16 
17
18int main(void) {
19
20pthread_t t;  
21
22pthread_create(&t, 0, doit, 0); // サブスレッド作成?起動
23
24                                // 做成并啟動子線程
25
26    if (fork() == 0) {
27
28        // 子プロセス。
29
30        // 子プロセスが生成される瞬間、親のサブスレッドはnanosleep中の場合が多い。
31
32        //子進程
33
34        //在子進程被創(chuàng)建的瞬間,父的子進程在執(zhí)行nanosleep的場合比較多
35
36        doit(0); return 0;
37
38    }
39
40pthread_join(t, 0); // サブスレッド完了待ち
41
42                    // 等待子線程結束
43
44}
45

以下にデッドロックの理由を説明いたします。
以下是說明死鎖的理由.

一般に、forkを行うと
一般的,fork做如下事情

1. 親プロセスの「データ領域」は子プロセスにそのままコピー
2. 子プロセスは、シングルスレッド狀態(tài)で生成

1. 父進程的內存數(shù)據(jù)會原封不動的拷貝到子進程中
2. 子進程在單線程狀態(tài)下被生成

されます。データ領域には、靜的記憶域を持つ変數(shù)*2が格納されていますが、それらは子プロセスにコピーされます。また、親プロセスにスレッドが複數(shù)存在していても、子プロセスにそれらは継承されません。forkに関する上記2つの特徴がデッドロックの原因となります。
在內存區(qū)域里,靜態(tài)變量*2mutex的內存會被拷貝到子進程里.而且,父進程里即使存在多個線程,但它們也不會被繼承到子進程里. fork的這兩個特征就是造成死鎖的原因.
譯者注: 死鎖原因的詳細解釋 ---
    1. 線程里的doit()先執(zhí)行.
    2. doit執(zhí)行的時候會給互斥體變量mutex加鎖.
    3. mutex變量的內容會原樣拷貝到fork出來的子進程中(在此之前,mutex變量的內容已經被線程改寫成鎖定狀態(tài)).
    4. 子進程再次調用doit的時候,在鎖定互斥體mutex的時候會發(fā)現(xiàn)它已經被加鎖,所以就一直等待,直到擁有該互斥體的進程釋放它(實際上沒有人擁有這個mutex鎖).
    5. 線程的doit執(zhí)行完成之前會把自己的mutex釋放,但這是的mutex和子進程里的mutex已經是兩份內存.所以即使釋放了mutex鎖也不會對子進程里的mutex造成什么影響.

例えば次のようなシナリオを考えてみてください。上記のマルチスレッドプログラムでの不用意なforkによって子プロセスがデッドロックすることがわかると思います*3。
例如,請試著考慮下面那樣的執(zhí)行流程,就明白為什么在上面多線程程序里不經意地使用fork就造成死鎖了*3.

1.    fork前の親プロセスでは、スレッド1と2が動いている

2.    スレッド1がdoit関數(shù)を呼ぶ

3.    doit関數(shù)が自身のmutexをロックする

4.    スレッド1がnanosleepを実行し、寢る

5.    ここで処理がスレッド2に切り替わる

6.    スレッド2がfork関數(shù)を呼ぶ

7.    子プロセスが生成される。

8.    この時、子プロセスのdoit関數(shù)用mutexは「ロック狀態(tài)」である。また、ロック狀態(tài)を解除するスレッドは子プロセス中には存在しない!

9.    子プロセスが処理を開始する。

10.        子プロセスがdoit関數(shù)を呼ぶ

11.        子プロセスがロック済みのmutexを再ロックしてしまい、デッドロックする

1.    在fork前的父進程中,啟動了線程1和2

2.    線程1調用doit函數(shù)

3.    doit函數(shù)鎖定自己的mutex

4.    線程1執(zhí)行nanosleep函數(shù)睡10秒

5.    在這兒程序處理切換到線程2

6.    線程2調用fork函數(shù)

7.    生成子進程

8.    這時,子進程的doit函數(shù)用的mutex處于”鎖定狀態(tài)”,而且,解除鎖定的線程在子進程里不存在

9.    子進程的處理開始

10.子進程調用doit函數(shù)

11.子進程再次鎖定已經是被鎖定狀態(tài)的mutex,然后就造成死鎖

このdoit関數(shù)のように、マルチスレッド下でのforkで問題を引き起こす関數(shù)を、「fork-unsafeな関數(shù)」と呼ぶことがあります。逆に、問題を起こさない関數(shù)を「fork-safeな関數(shù)」と呼ぶことがあります。一部の商用UNIX*4では、OSの提供する関數(shù)について、ドキュメントにfork-safetyの記載がありますが、Linux(glibc)にはもちろん! 記載がありません。POSIXでも特に規(guī)定がありませんので、どの関數(shù)がfork-safeであるかは殆ど判別不能です。わからなければunsafeと考えるほうが良いでしょう。 (2004/9/12 追記) Wolfram Glogerさんが非同期シグナルセーフな関數(shù)を呼ぶのは規(guī)格準拠と言っておられるので調べてみたら、pthread_atforkのところに "In the meantime*5, only a short list of async-signal-safe library routines are promised to be available." とありました。そういうことのようです。
像這里的doit函數(shù)那樣的,在多線程里因為fork而引起問題的函數(shù),我們把它叫做”fork-unsafe函數(shù)”.反之,不能引起問題的函數(shù)叫做”fork-safe函數(shù)”.雖然在一些商用的UNIX里,源于OS提供的函數(shù)(系統(tǒng)調用),在文檔里有fork-safety的記載,但是在Linux(glibc)里當然!不會被記載.即使在POSIX里也沒有特別的規(guī)定,所以那些函數(shù)是fork-safe的,幾乎不能判別.不明白的話,作為unsafe考慮的話會比較好一點吧.(2004/9/12追記)Wolfram Gloger說過,調用異步信號安全函數(shù)是規(guī)格標準,所以試著調查了一下,在pthread_atforkの這個地方里有” In the meantime*5, only a short list of async-signal-safe library routines are promised to be available.”這樣的話.好像就是這樣.

ちなみに、malloc関數(shù)は自身に固有のmutexを持っているのが通例ですので、普通はfork-unsafeです。malloc関數(shù)に依存する數(shù)多くの関數(shù)、例えばprintf関數(shù)などもfork-unsafeとなります。
隨便說一下,malloc函數(shù)就是一個維持自身固有mutex的典型例子,通常情況下它是fork-unsafe的.依賴于malloc函數(shù)的函數(shù)有很多,例如printf函數(shù)等,也是變成fork-unsafe的.

いままでthread+forkは危険と書いてきましたが、一つだけ特例があります。「fork直後にすぐexecする場合は、特例として問題がない」のです。何故でしょう..？exec系関數(shù)*6が 呼ばれると、プロセスの「データ領域」は一旦綺麗な狀態(tài)にリセットされます。したがって、マルチスレッド狀態(tài)のプロセスであっても、fork後にすぐ、危 険な関數(shù)を一切呼ばずにexec関數(shù)を呼べば、子プロセスが誤動作することはないのです。ただし、「すぐ」と書いてあることに注意してください。exec前に printf(“I’m child process”); を一発呼ぶだけでもデッドロックの危険があります!
直到目前為止,已經寫上了thread+fork是危險的,但是有一個特例需要告訴大家.”fork后馬上調用exec的場合,是作為一個特列不會產生問題的”. 什么原因呢..? exec函數(shù)*6一被調用,進程的”內存數(shù)據(jù)”就被臨時重置成非常漂亮的狀態(tài).因此,即使在多線程狀態(tài)的進程里,fork后不馬上調用一切危險的函數(shù),只是調用exec函數(shù)的話,子進程將不會產生任何的誤動作.但是,請注意這里使用的”馬上”這個詞.即使exec前僅僅只是調用一回printf(“I’m child process”),也會有死鎖的危險.
譯者注:exec函數(shù)里指明的命令一被執(zhí)行,改命令的內存映像就會覆蓋父進程的內存空間.所以,父進程里的任何數(shù)據(jù)將不復存在.

災いをどう回避するか
如何規(guī)避災難呢?

マルチスレッドのプログラムでのforkを安全に行うための、デッドロック問題回避の方法はあるでしょうか？いくつか考えてみます。
為了在多線程的程序中安全的使用fork,而規(guī)避死鎖問題的方法有嗎?試著考慮幾個.

回避方法１: forkを行う場合は、それに先立って他スレッドを全て終了させる
規(guī)避方法1:做fork的時候,在它之前讓其他的線程完全終止.

forkに先立って他スレッドを全て終了させておけば、問題はおきません。ただ、それが可能なケースばかりではないでしょう。また、何らかの要因で他スレッドの終了が行われないままforkしてしまった場合、解析困難な不具合して問題が表面化してしまいます。
在fork之前,讓其他的線程完全終止的話,則不會引起問題.但這僅僅是可能的情況.還有,因為一些原因而其他線程不能結束就執(zhí)行了fork的時候,就會是產生出一些解析困難的不具合的問題.

回避方法２: fork直後に子プロセスがexecを呼ぶようにする
規(guī)避方法2:fork后在子進程中馬上調用exec函數(shù)

(2004/9/11 書き忘れていたので追記)
(2004/9/11 追記一些忘了寫的東西)

回 避方法1が取れない場合は、子プロセスはfork直後に、どんな関數(shù)(printfなどを含む)も呼ばずにすぐにexeclなど、execファミリーの関 數(shù)を呼ぶようにします。もし、"execしないfork"を一切使わないプログラムであれば、現(xiàn)実的な回避方法でしょう。
不用使用規(guī)避方法1的時候,在fork后不調用任何函數(shù)(printf等)就馬上調用execl等,exec系列的函數(shù).如果在程序里不使用”沒有exec就fork”的話,這應該就是實際的規(guī)避方法吧.
譯者注:筆者的意思可能是把原本子進程應該做的事情寫成一個單獨的程序,編譯成可執(zhí)行程序后由exec函數(shù)來調用.

回避方法３: 「他スレッド」ではfork-unsafeな処理を一切行わない
規(guī)避方法3:”其他線程”中,不做fork-unsafe的處理

forkを呼ぶスレッドを除く全てのスレッドが、fork-unsafeな処理を一切行わない方法です。數(shù)値計算の速度向上目的でスレッドを使用している場合*7などは、なんとか可能かもしれませんが、一般のアプリケーションでは現(xiàn)実的ではありません。どの関數(shù)がfork-safeなのか把握することだけでも容易ではないからです。fork-safeな関數(shù)、要するに非同期シグナルセーフな関數(shù)ですが、それは數(shù)えるほどしかないからです。この方法では malloc/new, printf すら使えなくなってしまいます。
除了調用fork的線程,其他的所有線程不要做fork-unsafe的處理.為了提高數(shù)值計算的速度而使用線程的場合*7,這可能是fork-safe的處理,但是在一般的應用程序里則不是這樣的.即使僅僅是把握了那些函數(shù)是fork-safe的,做起來還不是很容易的.fork-safe函數(shù),必須是異步信號安全函數(shù),而他們都是能數(shù)的過來的.因此,malloc/new,printf這些函數(shù)是不能使用的.

回避方法４: pthread_atfork関數(shù)を用いて、fork前後に自分で用意したコールバック関數(shù)を呼んでもらう
規(guī)避方法4:使用pthread_atfork函數(shù),在即將fork之前調用事先準備的回調函數(shù).

pthread_atfork 関數(shù)を用いて、fork前後に自分で用意したコールバック関數(shù)を呼んでもらい、コールバック內で、プロセスのデータ領域を掃除する方法です。しかし、OS 提供の関數(shù)(例: malloc)については、コールバック関數(shù)から掃除する方法がありません。mallocの使用するデータ構造は外部からは見えないからです。よって、 pthread_atfork関數(shù)はあまり実用的ではありません。
使用pthread_atfork函數(shù),在即將fork之前調用事先準備的回調函數(shù),在這個回調函數(shù)內,協(xié)商清除進程的內存數(shù)據(jù).但是關于OS提供的函數(shù)(例:malloc),在回調函數(shù)里沒有清除它的方法.因為malloc里使用的數(shù)據(jù)結構在外部是看不見的.因此,pthread_atfork函數(shù)幾乎是沒有什么實用價值的.

回避方法５: マルチスレッドのプログラムでは、forkを一切使用しない
規(guī)避方法5:在多線程程序里,不使用fork

forkを一切使用しない方法です。forkするのではなく、素直にpthread_createするようにします。これも、回避策２と同様に現(xiàn)実的な方法であり、推奨できます。
就是不使用fork的方法.即用pthread_create來代替fork.這跟規(guī)避策2一樣都是比較實際的方法,值得推薦.

*1：子プロセスを生成するシステムコール
*1：生成子進程的系統(tǒng)調用

*2：グローバル変數(shù)や関數(shù)內のstatic変數(shù)
*2：全局變量和函數(shù)內的靜態(tài)變量

*3：Linuxを使用するのであれば、pthread_atfork関數(shù)のman pageを見るとよいです。この種のシナリオについて若干の解説があります
*3：如果使用Linux的話,查看pthread_atfork函數(shù)的man手冊比較好.關于這些流程都有一些解釋.

*4：SolarisやHP-UXなど
*4：Solaris和HP-UX等

*5：fork後execするまでの間
*5：從fork后到exec執(zhí)行的這段時間

*6：≒execveシステムコール
*6：≒execve系統(tǒng)調用

*7：四則演算しか行わないならfork-safe
*7：僅僅做四則演算的話就是fork-safe的

原文地址:http://d.hatena.ne.jp/yupo5656/20040715/p1