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

隨筆 - 119  文章 - 290  trackbacks - 0

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

常用鏈接

留言簿(12)

隨筆分類

我的博客

搜索

  •  

積分與排名

  • 積分 - 306390
  • 排名 - 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 閱讀(2334) 評論(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是如何處理這一關系的呢?  回復  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
              亚洲精品免费观看| 亚洲欧洲日产国产综合网| 国产精品美女久久久久久久| 在线免费观看日韩欧美| 亚洲免费人成在线视频观看| 欧美激情一区在线观看| 亚洲欧美日韩久久精品| 国产精一区二区三区| 欧美成人免费观看| 国产精品一区三区| 亚洲欧美一区二区激情| 亚洲无线一线二线三线区别av| 欧美日韩免费观看一区| 一区二区高清视频在线观看| 亚洲精品免费一二三区| 欧美福利精品| 夜久久久久久| 99在线精品观看| 欧美日一区二区在线观看| 亚洲一区二区av电影| 亚洲影视中文字幕| 国产日韩亚洲欧美| 久久这里只有| 另类欧美日韩国产在线| 亚洲经典自拍| 亚洲精品九九| 国产精品日韩久久久| 久久精品三级| 欧美电影免费观看| 亚洲一区欧美| 欧美一区国产一区| 亚洲国产精品欧美一二99| 亚洲承认在线| 欧美私人啪啪vps| 久久国产日韩欧美| 免费日韩av| 亚洲网在线观看| 欧美一区二区黄色| 亚洲韩日在线| 亚洲一区精品在线| 亚洲激情网站| 亚洲午夜国产一区99re久久| 韩国av一区二区三区| 欧美激情一区二区| 国产精品日韩欧美一区| 在线电影欧美日韩一区二区私密| 亚洲福利在线看| 国产精品视频导航| 亚洲高清在线视频| 国产免费成人| 亚洲日本一区二区| 国产日韩亚洲欧美| 91久久精品国产91久久| 国产一区日韩一区| 一本色道88久久加勒比精品| 在线成人免费视频| 午夜精品偷拍| 欧美激情精品| 久久国产精品99国产精| 欧美日韩国产一区二区三区| 久久久福利视频| 欧美调教视频| 亚洲国产日韩在线一区模特| 国产一区99| 在线视频免费在线观看一区二区| 亚洲第一在线| 欧美在线视频免费| 亚洲一区久久| 欧美精品在线一区二区| 欧美11—12娇小xxxx| 国产亚洲欧美一区在线观看| 中文网丁香综合网| 一区二区三区四区五区视频| 久久综合一区二区| 久久久欧美精品| 国产精品欧美日韩| 日韩网站在线| 日韩午夜高潮| 欧美搞黄网站| 亚洲电影第1页| 亚洲高清不卡一区| 久久久久一区二区三区| 久久久久国产成人精品亚洲午夜| 国产精品日韩精品| 亚洲免费在线观看| 香蕉视频成人在线观看| 国产精品丝袜久久久久久app| 一区二区三区四区国产精品| av成人激情| 欧美日韩午夜视频在线观看| 亚洲破处大片| 一区二区三区精品视频| 欧美日韩亚洲91| 在线亚洲免费| 小处雏高清一区二区三区| 欧美性一区二区| 亚洲毛片av| 亚洲一区精品视频| 国产美女一区| 久久精品视频免费播放| 免费黄网站欧美| 亚洲激情欧美激情| 欧美黄色影院| 一本到高清视频免费精品| 一区二区三区四区五区在线| 欧美日韩国产在线播放| 亚洲手机在线| 久久天天躁狠狠躁夜夜爽蜜月| 精品成人国产| 欧美国产日韩视频| 亚洲一二三区在线观看| 国产精品丝袜白浆摸在线| 亚洲欧美日韩成人高清在线一区| 久久精品国产一区二区三| 久久精品欧洲| 欧美在线中文字幕| 国产麻豆日韩| 狂野欧美一区| 亚洲欧洲午夜| 亚洲欧美日韩视频二区| 国语自产精品视频在线看| 巨胸喷奶水www久久久免费动漫| 亚洲国产精品va| 亚洲尤物在线视频观看| 国产一区二区剧情av在线| 老司机一区二区三区| 一级日韩一区在线观看| 久久国产精品久久精品国产| 亚洲国产高清自拍| 欧美午夜精品久久久| 久久久九九九九| 亚洲精品一二区| 久久久爽爽爽美女图片| 亚洲另类黄色| 国产真实精品久久二三区| 欧美黑人在线播放| 亚洲欧美日本视频在线观看| 亚洲国产精品黑人久久久| 亚欧成人精品| 亚洲精品一区二区三区福利| 国产欧美日韩亚州综合| 欧美啪啪成人vr| 久久久人成影片一区二区三区观看 | 亚洲精品日日夜夜| 久久久久久久精| 制服丝袜激情欧洲亚洲| 好吊一区二区三区| 欧美三级免费| 女女同性女同一区二区三区91| 亚洲你懂的在线视频| 亚洲国产一区二区三区在线播 | 欧美中文在线字幕| 日韩视频在线观看| 精品不卡一区| 国产区亚洲区欧美区| 欧美日韩在线观看一区二区三区| 久久久蜜臀国产一区二区| 亚洲午夜久久久久久尤物| 亚洲国产va精品久久久不卡综合| 久久久99久久精品女同性| 中国成人黄色视屏| 99热精品在线观看| 亚洲区第一页| 91久久国产综合久久蜜月精品 | 影音先锋成人资源站| 国产精品狠色婷| 欧美日韩妖精视频| 欧美另类亚洲| 欧美精品成人在线| 奶水喷射视频一区| 久久久免费av| 久久久久国产成人精品亚洲午夜| 午夜激情亚洲| 午夜精品999| 午夜精品短视频| 先锋亚洲精品| 欧美专区第一页| 久久久久免费观看| 久久影院午夜论| 久久久欧美一区二区| 久久久久久久一区二区三区| 久久成人这里只有精品| 久久精品道一区二区三区| 国产主播精品在线| 国产精品久久久久久久久 | 亚洲电影自拍| 一本色道久久88精品综合| 久久一本综合频道| 亚洲日本激情| aaa亚洲精品一二三区| 夜夜爽www精品| 国产精品99久久久久久www| 一区二区三区欧美激情| 亚洲一级特黄| 久久福利影视| 久久综合五月| 亚洲国产一区二区精品专区| 亚洲人成人一区二区在线观看 | 久久亚洲综合色| 乱中年女人伦av一区二区|