• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303672
            • 排名 - 84

            最新評論

            閱讀排行榜

            UNIX文化,提倡的是一種簡潔,直觀,低復雜度的文化.
            UNIX倡導多進程編程,而不是大家所熟悉的多線程編程.
            由于進程有自己獨立的地址空間,因此多進程之間的協作與交互,通關操作系統提供的各種IPC方法實現.
            在討論IPC的那個章節里,提出了管道,信號,臨時文件,共享內存,套接字幾個模型.

            我一般寫東西玩的時候,總是喜歡建立控制臺程序,因為輸入輸出庫都比較簡單,并且所見即得.管道/重定向之類,都是建立在標準輸入/輸出的基礎上.這里所描述的管道/重定向,并不是在一個進程中調用CreatePipe,改變管道方向,然后用CreateProcess建立一個子進程.UNIX所用的方式類似于.bat命令,比如 dir | more,用符號"|"連接兩個進程的管道.事實上,一般能用上管道/重定向的進程,都是一個過濾器,數據從標準輸入進來,經過加工后從標準輸出跑掉.因此,管道/重定向技術對于流水線般加工的任務,是一個相當棒的模型.
            需要注意的是,使用管道模型的程序,通常數據流/協議(在某個任務下)是單向的.
            總體上,在WINDOWS下像UNIX那樣使用管道/重定向機制,通常是用C/C++寫許多獨立但是可以連接的程序,然后用bat的方式,將其按所需任務組合.如果希望在程序中可以像bat那樣啟動其他進程,只要用簡單的system(command)函數就好了,WINAPI通常都是復雜而累贅的.

            UNIX下的信號,是對進程發出的,由進程的相應回調函數處理,程序可以重載自己的實現.這和WINDOWS下的消息比較相像,只是WM通常都需要窗口.由于信號/消息能傳遞的數據都比較薄弱簡單,所以這通常作為一種輔助機制,和其他IPC模型共同協作.

            臨時文件,是一種能解決雙向溝通的模型,但是并不利于做復雜的事情,最好的用途是在簡單,需要雙方溝通,大數據量的情形下.使用方法大概描述為,A進程調用執行某個任務的B進程,B進程將執行結果寫入A進程指定的文件,A進程使用該文件.
            一個隱患是,一旦破壞程序知道臨時文件的位置,就可能破壞該文件.
            其實臨時文件和接下來所說的共享內存在功能上并無太大區別.唯一不同的是,臨時文件所使用的API,都是很容易跨平臺的.

            共享內存,是一個和操作系統密切相關的IPC模型,作為生產者/消費者系統的一個性能優化的解決方案,其最大的優勢便是對大型數據傳遞所提供的效率.但是,預防競爭/死鎖是必須考慮的問題.我覺得,由于共享內存的API通常是專有的,不易于跨平臺,所以使用共享內存的條件應該比較嚴格,必須要在性能需求高和一次數據交換量巨大的情況下才可以考慮,而且,臨時文件是一個可以考慮的替代模型.

            套接字,是一個直觀并且在眾多操作系統中廣泛使用的模型,不用說也知道是一個好東西了.

            在《UNIX編程藝術》中,認為大多數的IPC方法都是可以相互替代的,因此最重要的是選擇一個盡可能使系統簡單的模型.此外,特別說多線程不該是最先考慮到的方法,而是最后一個.
            多線程將子任務糅合在一個程序中,而不是分開,增加了全局復雜度.此外,多線程帶來的2個不可避免的BUG:時序問題,還有競爭/死鎖的問題.縱然全局變量提升了任務之間的溝通效率,但是通常這種效率都被昂貴的鎖定/解鎖所抵消了.
            特別是,使用多線程的程序所依賴的庫,并非都是線程安全的,其中一旦產生的問題,會使得你麻煩重重,特別是,多線程的程序調試......由于時序問題,你自己想想都知道了.
            因此,非要使用多線程,理想(意味著不可能存在)的約束是,線程盡量不使用全局變量;每個變量只被一個線程使用;被線程使用的變量不再被主進程使用;線程中不使用static變量.....這種約束,根本沒有辦法實現嘛.

            posted on 2006-08-13 11:06 LOGOS 閱讀(2312) 評論(8)  編輯 收藏 引用 所屬分類: 《UNIX編程藝術》讀書筆記

            FeedBack:
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-14 17:19 yifeng
            首先謝謝你的文章。
            你說的這一段書,我也有看,但存在疑問。

            線程A發生內存溢出,可能會波及到線程B。
            或因為線程A的錯誤,使程序崩潰,連帶波及線程B。
            這些意外狀況,是我唯一想到的差別。
            (還有你說的開發過程中難調試的問題)

            除此,我沒想到實際差別。
            任務邏輯解耦得好,和使用進程或線程沒有關系
            如果一個進程的運行完全不需要和另一個進程通信,
            那么設計出來的線程任務也一樣不需要通訊,反之亦然。

            一般,使用對象,能把線程任務封裝得很好,輸入和輸出清晰。
            兩個進程使用共享內存,也需要保護,其情況和線程間共享數據結構無異。

            所以我不能理解把“時序問題、競爭/死鎖問題”歸為線程帶來問題。

            為此我想到了一種解釋,就是進程模型喜歡使用耦合度更低的通訊模式,例如Socket,
            而用線程的人則一般不愿意這樣做,而是直接回調,共享數據結構。
            不是因為線程模型比進程模型會帶來復雜,
            而是因為選用了不同的通訊手段,導致復雜性不同。  回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-14 19:35 LOGOS
            呵呵.怎么說呢.
            討論IPC,就說明討論的是需要通訊的任務(進程/線程).
            線程與進程的本質區別,應該是地址空間問題.進程是獨立的,線程是共享的.
            UNIX的元老們最害怕的應該就是沒有隱私吧.
            線程的通訊方式通常是共享數據結構(全局變量),全局變量是單份的,線程們要使用的話,必須競爭.如果線程過多,資源的分布過分復雜,也許會有意想不到的死鎖問題.通常死鎖....誰能預見呢?
            至于時序問題,其實在大學有認真學習過"操作系統",都知道怎么完美的控制各個任務的執行時序的.
            的確,不能說“時序問題、競爭/死鎖問題”歸為線程帶來問題,不過這兩個問題領域,似乎是在線程編程的時候才顯得尤其突出的.

            使用對象的確能把線程封裝得很好,不過這種很好,仔細想想,是對于不需要通訊的線程很好吧.只要用全局變量進行通訊,還是會繞回原來的點上.

            另外,將任務做成進程而不是線程還基于這樣一個理由,重用.
            雖然說線程的代碼包裝得好,可以像一個類庫一樣重用.但是一個進程的重用,是在編譯成一個執行文件之后,用批處理調用的重用.
            你覺得是一個類(包含不少接口,并且有調用順序/環境之類的約束,要命的是好像它還是線程)重用得順手,還是像"SomeTast.exe -SomeParam"這樣在主程序中執行bat命令舒坦呢?
            因人而異吧.

            并沒有反對線程的意思.只是想說,能用簡單的先用簡單的吧.下班越早越好,是吧.  回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-15 11:37 yifeng
            啊,別誤會,沒有說誰反對線程或進程的意思。
            只是單純的探討。

            我認為只要有并發和競爭就會有死鎖的可能,進程也不例外。
            我最大的疑問是,我假想不出具體的情形,能說明線程遭遇的問題比進程更突出。
            而我只能理解為"他們使用了不同的通訊手段"

            我的工作語言是C++,線程共享的一般不會是全局對象,而是局部的。
            在創建線程任務時,讓他們持有共享對象的句柄。
            目前為止,我未發現在控制他們的生命周期上有困難。
            所以也沒有發現使用全局對象的必要。

            但,一般我會在資源上使用大粒度鎖,假如我沒有發現功能或性能上有細化的必要。
            這也就盡量避免了拿到了叉子等刀子的情況。
            線程過多,資源的分布過分復雜的情況,的確很難控制。
            但也使我懷疑這種情況下使用進程模型是否合適。
              回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-15 12:43 LOGOS[offline]
            和你討論線程,我有點心虛.因為我對線程僅限于概念性認識而已.
            你說"在創建線程任務時,讓他們持有共享對象的句柄。", 這個"共享對象句柄"不是全局的嗎?我猜你的意思可能是他們的生命周期處于一個局部過程內,但是會比持有他們線程要長,也就是主函數內.那么我想拓展我所說的全局的意思,廣義上,凡是被多個線程競爭的變量,其意義都和全局變量無異.
            事實上,我所在意的也就是線程競爭變量的問題.因為那些變量用于通訊.

            對于資源分布復雜,我覺得這對進程沒有多大影響.因為在討論線程的時候,所謂的資源只是簡單的指那些被競爭的變量.對于進程而言,通信的數據都是以副本存在的.可能你的意思是像文件之類的資源,這種資源屬于硬件資源,由于本身的有限性,無論如何也都要競爭啦.

            應該說,線程一樣可以很好的編程,很好的工作.但是UNIX文化中極力提倡程序是可以腳本化的(也就是批處理文件那樣子),以便于復用.這一點線程好像沒什么辦法可以做到哦,再加上不統一的API問題,所以也就不怎么被推薦.
            此外,考慮到本書作者是一個憤青(譯者說),徹底的反GUI,反二進制的家伙,偏見也就不足為其了.  回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-15 12:46 LOGOS[offline]
            PS:進程在管道模型下,腳本包裝模型下,可以認為是順序工作的.在套接字下是并發工作. 同時獨立的地址空間.
            而線程一開始就是并發,而且共生共用的.  回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2006-08-16 10:20 lingate
            所謂的"徹底的反GUI,反二進制的家伙",實在言過其實了,因為作者一再強調界面和策略相關,而且在例子中作者推薦了一款業余人員特別喜歡的發送郵件的軟件,作者就認為界面設計很好,即照顧了普通用戶的需要又很好的顯示程序的狀態。在后面的大量篇幅中作者一直在說明程序編寫需要簡單性與透明性,也是一個標準的以人為本的思路,譯者的一家之言,請不要因此用帶色眼鏡看他。  回復  更多評論
              
            # re: IPC,????Unix???????????¸? 2007-08-10 18:36 xmlscript@hotmail.com
            ????????д???webserver???????????windows???????????????unix?汾????????????ö????????????б??unix??????ö?????
            ?????unix????????????????????????win32???????unix?µ????????webserver????δ??????????????  回復  更多評論
              
            # re: IPC,讀《Unix編程藝術》某章感 2007-08-10 18:37 xmlscript@hotmail.com
            我最近在編寫一個webserver,為方便,先在windows里構件,最終目的是unix版本。很自然我要使用多線程,但你文中表示unix下最好用多進程?
            由于對unix的無知和向往,使我暫停了手頭win32的開發。unix下的成熟的商業webserver是如何處理這一關系的呢?  回復  更多評論
              
            午夜精品久久久久| 久久久久久亚洲精品不卡| 久久综合久久自在自线精品自| 少妇久久久久久被弄高潮| 色综合久久中文综合网| 日本五月天婷久久网站| 91精品国产91久久久久久青草 | 久久亚洲精品人成综合网| 精品999久久久久久中文字幕| 日批日出水久久亚洲精品tv| 97久久超碰成人精品网站| 四虎久久影院| 国产福利电影一区二区三区久久老子无码午夜伦不 | 久久99精品国产麻豆婷婷| 亚洲精品乱码久久久久久久久久久久| 国产免费福利体检区久久 | 亚洲精品无码久久久影院相关影片| 久久精品九九亚洲精品天堂| 欧美日韩精品久久久久| 欧美一级久久久久久久大片| 99久久国产综合精品成人影院| 婷婷伊人久久大香线蕉AV | 久久丝袜精品中文字幕| 国产产无码乱码精品久久鸭| 欧美大香线蕉线伊人久久| 久久久久久久97| 久久婷婷五月综合色奶水99啪| 人妻中文久久久久| 久久精品中文字幕有码| 久久99精品国产麻豆婷婷| 精品久久久久久国产三级| 激情综合色综合久久综合| 国产日韩欧美久久| 国产成人久久777777| 久久久久国产精品嫩草影院 | 久久精品黄AA片一区二区三区| 少妇无套内谢久久久久| 狠狠色狠狠色综合久久| 无码人妻久久一区二区三区免费丨| 亚洲va国产va天堂va久久| 人妻无码αv中文字幕久久|