青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

桃源谷

心靈的旅行

人生就是一場旅行,不在乎旅行的目的地,在乎的是沿途的風(fēng)景和看風(fēng)景的心情 !
posts - 32, comments - 42, trackbacks - 0, articles - 0
  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

準(zhǔn)則3:多線程程序里不準(zhǔn)使用fork

Posted on 2008-06-01 20:16 lymons 閱讀(13107) 評論(0)  編輯 收藏 引用 所屬分類: C++CUnix/Linux文章翻譯
From 2008精選

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

 

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

 

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

 

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

 

 1void* doit(void*{
 2
 3    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
 4
 5    pthread_mutex_lock(&mutex);
 6
 7    struct timespec ts = {100}; 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); // サブスレッド作成?起動(dòng)
23
24                                // 做成并啟動(dòng)子線程
25
26    if (fork() == 0{
27
28        // 子プロセス。
29
30        // 子プロセスが生成される瞬間、親のサブスレッドはnanosleep中の場合が多い。
31
32        //子進(jìn)程
33
34        //在子進(jìn)程被創(chuàng)建的瞬間,父的子進(jìn)程在執(zhí)行nanosleep的場合比較多
35
36        doit(0); return 0;
37
38    }

39
40pthread_join(t, 0); // サブスレッド完了待ち
41
42                    // 等待子線程結(jié)束
43
44}

45

 

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

 

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

  1. 親プロセスの「データ領(lǐng)域」は子プロセスにそのままコピー
  2. 子プロセスは、シングルスレッド狀態(tài)で生成
  1. 父進(jìn)程的內(nèi)存數(shù)據(jù)會(huì)原封不動(dòng)的拷貝到子進(jìn)程中
  2. 子進(jìn)程在單線程狀態(tài)下被生成

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

 

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

1.    fork前の親プロセスでは、スレッド12が動(dòng)いている

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

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

4.    スレッド1nanosleepを?qū)g行し、寢る

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

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

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

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

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

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

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

1.    fork前的父進(jìn)程中,啟動(dòng)了線程12

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

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

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

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

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

7.    生成子進(jìn)程

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

9.    子進(jìn)程的處理開始

10.子進(jìn)程調(diào)用doit函數(shù)

11.子進(jìn)程再次鎖定已經(jīng)是被鎖定狀態(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ī)格準(zhǔn)拠と言っておられるので調(diào)べてみたら、pthread_atforkのところ "In the meantime*5, only a short list of async-signal-safe library routines are promised to be available." とありました。そういうことのようです。
像這里的doit函數(shù)那樣的,在多線程里因?yàn)?span lang=EN-US>fork而引起問題的函數(shù),我們把它叫做”fork-unsafe函數(shù)”.反之,不能引起問題的函數(shù)叫做”fork-safe函數(shù)”.雖然在一些商用的UNIX,源于OS提供的函數(shù)(系統(tǒng)調(diào)用),在文檔里有fork-safety的記載,但是在Linux(glibc)里當(dāng)然!不會(huì)被記載.即使在POSIX里也沒有特別的規(guī)定,所以那些函數(shù)是fork-safe,幾乎不能判別.不明白的話,作為unsafe考慮的話會(huì)比較好一點(diǎn)吧.(2004/9/12追記)Wolfram Gloger說過,調(diào)用異步信號安全函數(shù)是規(guī)格標(biāo)準(zhǔn),所以試著調(diào)查了一下,pthread_atfork這個(gè)地方里有” 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ù)就是一個(gè)維持自身固有mutex的典型例子,通常情況下它是fork-unsafe.依賴于malloc函數(shù)的函數(shù)有很多,例如printf函數(shù)等,也是變成fork-unsafe.

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

pthread_atfork 関數(shù)を用いて、fork前後に自分で用意したコールバック関數(shù)を呼んでもらい、コールバック內(nèi)で、プロセスのデータ領(lǐng)域を掃除する方法です。しかし、OS 提供の関數(shù)(: malloc)については、コールバック関數(shù)から掃除する方法がありません。mallocの使用するデータ構(gòu)造は外部からは見えないからです。よって、 pthread_atfork関數(shù)はあまり実用的ではありません。
使用pthread_atfork函數(shù),在即將fork之前調(diào)用事先準(zhǔn)備的回調(diào)函數(shù),在這個(gè)回調(diào)函數(shù)內(nèi),協(xié)商清除進(jìn)程的內(nèi)存數(shù)據(jù).但是關(guān)于OS提供的函數(shù)(:malloc),在回調(diào)函數(shù)里沒有清除它的方法.因?yàn)?span lang=EN-US>malloc里使用的數(shù)據(jù)結(jié)構(gòu)在外部是看不見的.因此,pthread_atfork函數(shù)幾乎是沒有什么實(shí)用價(jià)值的.

 

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

 

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

 

*1:子プロセスを生成するシステムコール
*1:生成子進(jìn)程的系統(tǒng)調(diào)用

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

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

*4SolarisHP-UXなど
*4
SolarisHP-UX

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

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

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


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

我的個(gè)人簡歷第一頁 我的個(gè)人簡歷第二頁
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲国产精品一区二区久| 国产视频精品xxxx| 久久久久久久一区二区三区| 亚洲久久一区二区| 免费永久网站黄欧美| 午夜在线精品偷拍| 正在播放欧美一区| 亚洲国产一二三| 韩日欧美一区二区| 国产视频一区在线观看| 欧美日韩中文字幕在线| 欧美福利精品| 欧美成人a视频| 久久深夜福利免费观看| 欧美一级久久久| 午夜精品亚洲| 亚洲性人人天天夜夜摸| 日韩系列欧美系列| 亚洲国产日韩欧美在线图片 | 久久国产主播精品| 午夜精品在线| 亚洲欧美制服另类日韩| 亚洲一区二区不卡免费| 99这里有精品| 一区二区三区成人精品| 日韩视频免费| 一区二区三区高清不卡| 一区二区免费在线观看| 夜夜嗨av一区二区三区四季av| 亚洲日韩欧美视频| 亚洲人成7777| 99国内精品久久| 亚洲视频免费观看| 亚洲一区在线免费观看| 亚洲欧美日韩国产另类专区| 午夜欧美不卡精品aaaaa| 亚洲欧美一区二区三区极速播放 | 久久国产精品亚洲va麻豆| 午夜精品影院| 久久激情一区| 老司机午夜精品视频在线观看| 久久欧美肥婆一二区| 久久久精彩视频| 美女精品在线观看| 亚洲高清三级视频| 夜夜嗨网站十八久久| 一区二区三区视频在线播放| 亚洲在线免费视频| 欧美一区二区三区四区夜夜大片| 欧美一区二区视频在线观看2020| 久久国产成人| 欧美大胆成人| 欧美三区视频| 国产亚洲精久久久久久| 激情小说另类小说亚洲欧美| 亚洲人成77777在线观看网| 亚洲伦理中文字幕| 先锋影音久久| 农村妇女精品| 亚洲精品三级| 欧美一区二区在线| 米奇777在线欧美播放| 欧美日韩免费观看一区| 国产区欧美区日韩区| 激情综合视频| 亚洲一区二区三区777| 久久er精品视频| 亚洲高清不卡av| 亚洲一区二区三区欧美| 久久先锋影音| 国产精品久久久久91| 国语自产精品视频在线看一大j8| 亚洲精品一区二区网址| 午夜宅男欧美| 亚洲国产一区二区三区在线播 | 一区免费观看| 亚洲午夜一区二区| 久久综合狠狠综合久久激情| 亚洲欧洲一区二区三区| 亚洲欧美中文日韩在线| 欧美激情一区在线观看| 国模 一区 二区 三区| 99热精品在线| 美女黄毛**国产精品啪啪| 99精品热视频| 欧美成年人视频| 国产日本欧美一区二区三区| 亚洲麻豆国产自偷在线| 久久青青草综合| 一区二区三区四区蜜桃| 麻豆精品精品国产自在97香蕉| 国产精品你懂的| 亚洲人成在线影院| 老巨人导航500精品| 亚洲一区二区三区激情| 欧美激情一区二区久久久| 影音先锋成人资源站| 欧美一区不卡| 99日韩精品| 欧美激情综合五月色丁香小说 | 亚洲人成77777在线观看网| 亚洲欧美精品伊人久久| 欧美日韩一区二区在线视频 | 久久精品一区中文字幕| 99在线精品视频| 欧美www视频| 精品999在线播放| 久久国产欧美| 亚洲天堂av电影| 欧美日韩国产欧美日美国产精品| 在线观看日韩专区| 久久久精品日韩欧美| 亚洲欧美日韩高清| 国产精品久久久久永久免费观看| 日韩一本二本av| 91久久精品国产91性色| 卡通动漫国产精品| 在线观看精品视频| 久久久综合免费视频| 亚洲欧美综合一区| 国产嫩草影院久久久久 | 亚洲三级视频| 欧美大片在线看免费观看| 亚洲韩国一区二区三区| 欧美激情按摩| 欧美福利一区二区| 999亚洲国产精| 亚洲精品乱码久久久久久| 欧美日韩国产片| 亚洲伊人网站| 亚洲午夜一二三区视频| 国产精品久久久久国产精品日日 | 久久国产精品久久久久久电车| 国产精品在线看| 久久久国产一区二区| 久久精品卡一| 在线观看日韩国产| 亚洲国产裸拍裸体视频在线观看乱了中文 | 欧美精品v国产精品v日韩精品 | 麻豆av福利av久久av| 美腿丝袜亚洲色图| 99在线热播精品免费99热| 一区二区日韩欧美| 国产欧美日本在线| 免费久久99精品国产| 欧美a级大片| 亚洲色在线视频| 亚洲欧美精品在线观看| 一区视频在线| 亚洲欧洲视频在线| 国产精品视频999| 开心色5月久久精品| 欧美激情精品| 亚洲欧美日本国产有色| 久久国产手机看片| 亚洲精品在线二区| 亚洲深爱激情| 黄色影院成人| 亚洲欧洲视频在线| 国产欧美婷婷中文| 欧美国产欧美亚洲国产日韩mv天天看完整 | 国产一区二区三区在线观看免费| 久久综合久久久久88| 欧美成人免费视频| 亚洲欧美日韩国产综合在线 | 国产精品夜夜夜| 麻豆成人在线播放| 欧美日韩一区高清| 久久午夜视频| 欧美日韩a区| 久色成人在线| 欧美视频福利| 免费中文字幕日韩欧美| 欧美婷婷在线| 女生裸体视频一区二区三区| 欧美日韩免费在线视频| 久久综合亚州| 国产精品久久一卡二卡| 欧美成人三级在线| 国产精品老女人精品视频| 欧美成人国产va精品日本一级| 国产精品国产| 亚洲高清123| 韩国成人理伦片免费播放| 亚洲美女精品成人在线视频| 黄色一区二区三区四区| 亚洲午夜av电影| 亚洲精品欧美一区二区三区| 性色一区二区三区| 亚洲一区二区免费| 欧美成人r级一区二区三区| 久久精品视频免费播放| 欧美性猛交99久久久久99按摩 | 欧美高潮视频| 国产视频亚洲精品| 一本一本久久a久久精品综合妖精 一本一本久久a久久精品综合麻豆 | 欧美v日韩v国产v| 美女视频黄a大片欧美| 国产精品你懂的在线欣赏| 亚洲欧洲日产国码二区|