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

隨筆 - 119  文章 - 290  trackbacks - 0

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

常用鏈接

留言簿(12)

隨筆分類

我的博客

搜索

  •  

積分與排名

  • 積分 - 306391
  • 排名 - 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>
              最新国产成人在线观看| 亚洲人成网站精品片在线观看| 国产毛片一区二区| 亚洲欧美在线x视频| 欧美夫妇交换俱乐部在线观看| 久久综合给合久久狠狠色 | 久久成人一区| 久久久久久午夜| 欧美福利视频| 日韩视频在线一区二区| 亚洲永久在线| 久久久久天天天天| 欧美久久久久| 国产无一区二区| 91久久综合亚洲鲁鲁五月天| 亚洲午夜精品视频| 久久免费视频在线| 91久久国产自产拍夜夜嗨| 最新精品在线| 亚洲网址在线| 久久综合色8888| 国产精品福利在线| 国内精品视频在线播放| 亚洲伦理网站| 欧美中文字幕久久| 亚洲国产成人不卡| 午夜精品国产更新| 欧美精品在线一区| 国内成人精品2018免费看| 在线亚洲一区观看| 免费一级欧美片在线播放| 亚洲午夜一区二区三区| 麻豆91精品91久久久的内涵| 国产欧美一区二区精品秋霞影院| 亚洲欧洲日产国产综合网| 欧美在线三级| 99热这里只有成人精品国产| 久久综合久久综合这里只有精品| 国产欧美精品国产国产专区| 99国产精品私拍| 免费亚洲婷婷| 欧美一区永久视频免费观看| 欧美三级电影大全| 亚洲理论在线观看| 欧美成人精品激情在线观看| 欧美在线高清视频| 国产女精品视频网站免费| 亚洲深夜影院| 亚洲乱码国产乱码精品精天堂| 欧美 日韩 国产在线| 在线日韩av片| 久久婷婷av| 久久精品国亚洲| 国产在线日韩| 久久久99爱| 性色av一区二区三区| 国产精品亚洲第一区在线暖暖韩国| 夜夜嗨av一区二区三区免费区| 欧美国产日韩在线| 亚洲一区在线直播| 欧美自拍偷拍午夜视频| 亚洲国产精品久久久久| 久久精品五月| 韩国精品在线观看| 久热精品视频在线免费观看| 久久成人资源| 亚洲激情午夜| 亚洲精品三级| 欧美视频在线一区| 亚洲男人天堂2024| 亚洲小视频在线| 国产伦精品一区| 久久免费高清视频| 麻豆91精品91久久久的内涵| 亚洲精品在线免费观看视频| 亚洲伦理精品| 国产精品你懂的| 久久久久久久综合狠狠综合| 久久精品视频在线看| 91久久夜色精品国产九色| 91久久精品国产91久久性色tv | 黄色精品网站| 亚洲国产高清一区| 欧美午夜一区二区福利视频| 久久成人这里只有精品| 久久最新视频| 亚洲性夜色噜噜噜7777| 欧美制服丝袜第一页| 亚洲日本视频| 新67194成人永久网站| 亚洲靠逼com| 欧美一区二区三区久久精品| 日韩写真在线| 久久久精品日韩| 亚洲一级特黄| 狂野欧美性猛交xxxx巴西| 亚洲欧美欧美一区二区三区| 久久伊人一区二区| 午夜亚洲性色福利视频| 欧美不卡视频一区发布| 欧美在线1区| 欧美日韩激情网| 蜜臀va亚洲va欧美va天堂| 国产精品狠色婷| 91久久极品少妇xxxxⅹ软件| 精品二区久久| 亚洲一区美女视频在线观看免费| 日韩视频中文字幕| 久久久国产精品亚洲一区| 亚洲欧美影院| 欧美四级在线观看| 亚洲精品久久久久久久久| 国产中文一区二区三区| 这里只有精品电影| 日韩网站在线观看| 久久久久免费| 欧美主播一区二区三区| 欧美另类专区| 亚洲国产欧美日韩| 久久久亚洲影院你懂的| 一区二区黄色| 久久国产天堂福利天堂| 亚洲国产天堂久久国产91| 制服丝袜激情欧洲亚洲| 尤物九九久久国产精品的特点| 日韩亚洲精品电影| 亚洲视频第一页| 久久久精品免费视频| 亚洲色诱最新| 欧美成人高清| 在线视频精品一区| 欧美激情无毛| 老牛嫩草一区二区三区日本| 欧美性淫爽ww久久久久无| 亚洲福利在线看| 国自产拍偷拍福利精品免费一| 亚洲综合精品| 中文在线资源观看视频网站免费不卡| 久久国产精品毛片| 欧美一区日韩一区| 欧美午夜视频在线| 亚洲国产欧美另类丝袜| 精久久久久久| 欧美影视一区| 久久国产精品久久w女人spa| 欧美午夜不卡视频| 久久精品中文| 国产亚洲aⅴaaaaaa毛片| 在线视频中文亚洲| 亚洲自拍偷拍福利| 国产精品成av人在线视午夜片| 久久久青草青青国产亚洲免观| 国产精品久久毛片a| 久久精品国产精品亚洲精品| 久久成人免费| 国产区精品视频| 亚洲一区二区高清| 午夜激情亚洲| 国产精品日韩精品| 中文网丁香综合网| 小嫩嫩精品导航| 亚洲电影免费观看高清完整版在线| 久久激情视频久久| 欧美成人免费全部| 亚洲人妖在线| 国产伦精品一区二区三区高清版 | 欧美韩日一区二区| 在线欧美日韩| 模特精品在线| 欧美激情aaaa| 国产亚洲欧美一区二区三区| 免费国产一区二区| 亚洲人成网站999久久久综合| 99国产精品久久久久久久久久 | 性欧美8khd高清极品| 噜噜爱69成人精品| 亚洲国产精品精华液2区45| 美玉足脚交一区二区三区图片| 性做久久久久久久免费看| 亚洲国产成人不卡| 欧美另类videos死尸| 亚洲大胆视频| 亚洲资源av| 影音先锋亚洲精品| 欧美亚洲成人网| 久久精品亚洲| 亚洲日本在线观看| 久久爱www.| 国产精品腿扒开做爽爽爽挤奶网站| 欧美激情一区二区三区在线| 一区二区国产精品| 国产日韩欧美中文在线播放| 久久亚洲精品一区二区| 午夜久久久久久| 亚洲风情亚aⅴ在线发布| 午夜精品久久久久久久久久久久久 | 国产精品美女www爽爽爽| 欧美一区国产在线| 久久国产精品一区二区三区四区| 在线视频精品一|