計算機畢業(yè)設計外文翻譯現代并發(fā)抽象C#_第1頁
計算機畢業(yè)設計外文翻譯現代并發(fā)抽象C#_第2頁
計算機畢業(yè)設計外文翻譯現代并發(fā)抽象C#_第3頁
計算機畢業(yè)設計外文翻譯現代并發(fā)抽象C#_第4頁
計算機畢業(yè)設計外文翻譯現代并發(fā)抽象C#_第5頁
已閱讀5頁,還剩16頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、南京郵電大學畢業(yè)設計(論文)外文資料翻譯學 院傳媒與藝術學院專業(yè)數字媒體技術學生姓名黃超班級學號b080705 b08070525外文出處acm transactions on programming languages and systems, vol. 26, no. 5, september 2004附件:1.外文資料翻譯譯文;2.外文原文指導教師評價:1翻譯內容與課題的結合度: 優(yōu) 良 中 差2翻譯內容的準確、流暢: 優(yōu) 良 中 差3專業(yè)詞匯翻譯的準確性: 優(yōu) 良 中 差4翻譯字符數是否符合規(guī)定要求: 符合 不符合指導教師簽名:年月日附件1:外文資料翻譯譯文現代并發(fā)抽象c尼克本頓,盧卡

2、卡戴爾和塞德里克富爾微軟研究院1.1語言和并發(fā)并發(fā)是現代代碼中的一個重要實現形式:并發(fā)程序的編寫設計,解釋,調試,和調整都是有難度的。并發(fā)可以顯著影響一個結構中的語言的含義(開始轉讓的原子),并能影響調用庫的能力。盡管這樣,最流行的編程語言對待并發(fā)語言不是作為一種語言功能的并發(fā)性,而往往是作為一個收集的,根據指定的外部庫??紤]到這樣的事實后,規(guī)范的并發(fā)庫比勒爾等。 1987年;斯林等。 1996年detlefs等。 1998年古列維奇等。 2000 已給予相當的重視,通常通過這些規(guī)范就可以對他們的行為應該在何處執(zhí)行做出判斷。然而,即使當并發(fā)庫被正確指定,但由于他們是庫,而不是語言的特點這個事實

3、,還是會有不良的后果。在原則上,可以提供許多功能,無論是作為語言特性或作為庫:典型的例子是,內存管理和異常。有“語言”等功能的優(yōu)點是,編輯者可以對它們進行分析,因此可以產生更好的代碼,并警告親程序員的潛在和實際問題。特別是,編譯器可以檢查語法嵌入的變量,這將是很難從庫中提取調用的集合。此外,程序員可以更可靠說明自己的意圖,通過一個清晰的語法和其他工具比編輯者可以更容易地確定程序員的意圖。特定領域的語言ramming 1997; kamin 1997是一個極端的語言學方法的例子:經常提出新的特設語言并不是要取代通用的語言,而是為了方便特定于域的代碼分析域相關的功能,作為原始的語言表達簡單的事實結

4、構。我們相信,并發(fā)應該是一個語言功能的一部分和一種語言規(guī)范。在70年代開始在這個方向作了很多嘗試,顯示器霍爾1974年的概念和奧卡姆語言inmos有限公司1984(基于通信順序進程霍爾1985)。監(jiān)控器的一般概念已經變得非常流行,特別是在其目前的面向對象的形式線程和對象綁定互斥,但它已提供作為一個語法的外殼模板,最可選鎖定對象上的方法調用。許多事情因為監(jiān)控器被引入并發(fā)而已經改變。通信已變得更加的異步,并行計算一定要通過規(guī)模較大的“精心策劃”的。值得關注的是沒有那么多的有效的實施和使用鎖在一個單一的處理器或者多重處理器,但沒有不必要的異步事件的處理能力阻止長期客戶,并沒有死鎖。換句話說,重心正在

5、從共享內存并發(fā)轉向消息或事件并發(fā)性。這些新的要求應該得到可以處理異步通信和不束縛共享記憶的編程結構的方法。盡管出現大規(guī)模的模式設計如america 1989; agha et al.1993; reppy 1992; pierce and turner 2000; philippsen 1995,但只有監(jiān)控器獲得廣泛接受的編程結構。最近在富爾和gonthier的1996,2002加入演算中顯現了一個有趣的新的語言方法,進程演算非常適合在分布式的環(huán)境中直接執(zhí)行。其他語言,如jocaml conchon and le fessant 1999和 funnel odersky 2000,結合了類似功

6、能編程模型的想法。在這里,我們提出了一個加入演算想法的適應一個面向對象的語言,有一個現有線程和鎖的并發(fā)模型。 itzstein和kearney 2001最近為java描述非常類似的擴展。1.2異步編程異步的事件和消息傳遞越來越多地用于在各級軟件系統(tǒng)。在最低水平,設備驅動程序必須對異步設備事件迅速作出反應,而資源利用上的吝嗇。在圖形用戶界面級別是出了名的,復雜的代碼和編程模型,因為用戶事件的異步性質;在同一時間,用戶討厭被不必要的封鎖。在廣域網的水平,例如,在協(xié)作應用,分布式的工作流,web服務,我們現在遇到類似的問題,因為全球通信的異步性質和潛伏期和復雜性。在所有這些領域,我們自然會發(fā)現有很多

7、要處理的同時異步消息的情況下,多線程用來處理它們。主題仍然是一個在大多數系統(tǒng)中昂貴的資源。然而,如果我們能有些隱藏在背后的消息和線程使用一種語言機制,那么很多的選項成為可能。編譯器可狀態(tài)機轉換成并發(fā)的一些模式,優(yōu)化使用隊列,使用輕量級的線程,在可能的情況下,避免分叉線程沒有必要的,并使用線程池。這一切都是真的有可能只有一個擁有上譜“,可以發(fā)生的事情”:這個手柄可以處理由并發(fā)操作,既可以隱藏,從而使多個語法實現技術。因此,我們的目標是促進異步編程抽象是高層次的,從一個程序員的角度來看,使低層次的優(yōu)化,從一個編譯器和運行時系統(tǒng)的角度來看。我們提出用現代并發(fā)c語言的延伸異步編程抽象。在與音樂的精神調

8、諧的c和并發(fā)活動的“協(xié)調流程”,我們稱這種語言復調c。1.3 c# 和 .netc是一個現代,類型安全,面向對象編程語言,最近微軟推出的visual studio.net2001ecma的一部分。 c程序上運行.net框架,其中包括多語言的執(zhí)行頂部引擎和一個豐富的類庫集合。.net執(zhí)行引擎提供了一個多線程的執(zhí)行環(huán)境潛在的相互關聯(lián)與同步鎖ment在堆上分配的對象。c語言,包括一個lock語句,執(zhí)行的過程中獲得一個給定的對象相關聯(lián)的互斥阻塞。此外,.net庫實現了許多傳統(tǒng)的并發(fā)控制原語,如信號量,互斥和讀/寫鎖,以及異步編程模型的基礎上代表。.net框架還提供更高級別的基礎設施建設分布應用和服務,

9、如基于soap的消息傳遞和遠程方法打電話。.net framework中的并發(fā)和分配機制功能強大,但他們也不可否認復雜。且不說從原語,更多的或較少的基礎設施,在烤“讓人眼花繚亂,有一臺機器上(共享內存,線程,同步的基礎上的東西是20世紀70年代的并發(fā)模型之間的不匹配相互排斥)和異步,基于消息的風格,使用編程基于網絡的應用和服務。因此,c中似乎是一個為主流的并發(fā)語言支持我們的想法,理想的測試床語言。2。復調c語言概述本節(jié)介紹新構造復調的c語法和語義,然后給出了更精確,雖然仍是非正式的,規(guī)范語法。 2.1基本思路到c的相當傳統(tǒng)的面向對象編程模型,復調c增加了兩個新概念:異步方法和復調。異步方法。傳

10、統(tǒng)的方法是同步的,在檢測到來電者沒有取得任何進展,直到被叫方完成。復調c中,如果一個方法被聲明為異步調用任何保證立即基本上完成。異步方法永遠不會返回結果(或拋出異常);他們使用async關鍵字,而不是宣布無效。調用異步方法很像是發(fā)送消息,或張貼的事件。由于異步方法立即返回,方法的調用如下: async postevent(eventinfo data) / large method body是唯一可以合理地調用立即返回,“大被安排在不同的線程執(zhí)行方法體“(無論是一個新的催生了以服務這個呼叫,或者從一些游泳池的工人)。然而,這樣的定義,實際上是相當難得的c復調。更常見的異步方法是使用如下所述的復

11、調,定義,不一定需要新的線程。復調。復調(也被稱為“同步模式”,或“加盟模式”)由一個頭和一個身體。頭是一套方法聲明由“”分隔。身體只執(zhí)行一次所有的方法,在頭被稱為方法調用隱含排隊等候,直到/除非是有現代并發(fā)抽象為c匹配的復調。考慮,例如:public class buffer public string get() & public async put(string s) return s;上面的代碼定義了兩個實例方法的類的緩沖區(qū),這是共同定義在一個單一的復調。string get()方法是一個同步的方法不接受參數并返回一個字符串。async put(string s)方法是異步的(沒有返回

12、結果),并接受一個字符串參數。如果buff是緩沖和一個調用同步方法的的一個buff . get()實例。然后有兩種可能性: 如果有以前的未匹配過的的通話buff . put(s) (for some string s),那么現在有一個比賽,所以離隊待沽put(s)和復調的身體運行,返回到呼叫者的buff . get()方法。 如果是以前匹配過的來電buff . put(.),然后調用buff. get()方法阻塞,直到另一個線程提供了一個匹配的put()。相反,在調用異步方法的buff . put(.),來電從未等待,但對于其他線程可能有兩種行為: 如果有以前的未匹配過的通話buff . ge

13、t()再有就是現在的一次匹配,所以掛起調用出列和其相關阻塞的線程是喚醒運行的復調,返回值給s。 如果沒有掛起調用的buff.get(),然后調用到buff . put(s)僅僅是排隊,直到一個個到達。到底哪的電話匹配是不確定的,所以即使是單線程程序如:buffer buff = new buffer();buff . put(“blue”);buff . put(“sky”);console.write(buff . get() + buff . get();也是不確定的(印刷或者“藍天”或“天藍”)。請注意,執(zhí)行緩沖不涉及產生任何主題:復調本身在運行時,它在一個已經存在的線程(即一個名為ge

14、t())。讀者在這一點上可能會想什么規(guī)則決定在哪個線程體運行,或如何,我們知道,方法調用將返回人體所計算的最終價值。答案是,在任何給定的弦,最多的一種方法可能是同步的。如果有這種方法,然后身體在與調用線程運行這一號召的方法,并返回值。只是,如果沒有這樣的方法(即在弦的所有方法都是異步)運行在一個新的線程,在這種情況下,有沒有要返回的值。還應當指出,緩沖區(qū)的代碼,瑣碎,但它是,是線程安全的。需要鎖定(例如,以防止參數返回兩個不同的獲取到一個單放)自動生成由編譯器。更確切地說,決定是否任何復調呼叫啟用,如果是這樣,從隊列中刪除其他懸而未決的呼叫和調度為執(zhí)行機構,是一個原子操作。除了這個原子性的保證

15、,然而,有沒有監(jiān)視器像復調機構之間的相互排斥的。任何相互排斥的需要,必須明確在編程在弦頭的同步條件。緩沖區(qū)的例子定義了兩個方法使用一個單一的復調。這也是(普通)有涉及給定方法的多復調。例如:public class buffer public string get() & public async put(string s) return s;public string get() & public async put(int n) return n.tostring(); 現在我們已經定義為數據緩沖區(qū)的方法之一,但有兩個把它的方法(其中發(fā)生類型,而不是要區(qū)分比名)。get()調用可以同步調用

16、的put()方法。如果有排隊調用put()s,那么哪一個同步隨后get()是不確定的。3。非正式規(guī)范3.1語法到c語法的語法擴展ecma 2001, appendix c是非常次要的。我們添加一個新的關鍵字async,并添加它作為一種替代的返回類型:returntype : := type | void | async這使得方法,代表和接口方法被宣布異步的。在類成員的聲明中,我們更換方法聲明chorddeclaration : :=methodheader & methodheader bodymethodheader : :=屬性修飾符返回類型成員名(形參)。我們呼吁復調聲明微不足道的,如果

17、它宣布一個單一的,同步的方法(即它是一個標準的c方法聲明)。3.2良好的格式擴展類是格式良好的條件: 在一個單一的方法頭:(1)如果返回類型是異步的,那么正式的參數列表中的形參不得包含任何ref或out參數修飾符。 在一個單一的復調聲明:(2)最多的一種方法頭可能有非異步的返回類型。(3)如果弦有一個返回類型的類型的方法頭,然后身體可能使用返回類型的表達式的語句,否則身體可能使用空的return語句。(4)在方法頭中出現的所有形參必須有鮮明的標識。(5)兩種方法,頭可能沒有相同的成員名稱和相同的參數類型簽名。(6)的方法,頭必須全部申報的實例方法或所有聲明的靜態(tài)方法。 在一個特定的類:(7)具

18、有相同的成員名稱和參數類型的所有方法頭簽名必須具有相同的屬性的返回類型和相同的套和修飾符。(8)如果它是一個值類(結構),那么只有靜態(tài)方法可能會出現在不平凡的復調。(9)如果任何復調聲明包括一個覆蓋虛擬方法m修飾符,那么任何方法n出現在包含重寫定義的m的超弦與m也必須被重寫在子類中。這些條件大多是相當簡單的,但條件2和9值得我們進一步的評論。條件9提供了一個保守的,但簡單,完整性檢查時,煉油類包含復調以來,在一般情況下,實現繼承和并發(fā)不拌勻松岡和米澤1993(見富爾等。 2000連接的情況下討論了“繼承異?!蔽⒎e分)。這里是我們的方法來執(zhí)行這兩個關注點分離:一系列的復調,必須是當地的一類或子類

19、聲明的語法;方法重寫時,他們所有的復調還必須完全重寫。如果認為執(zhí)行一個給定的方法包括所有同步和機構,它出現的所有的復調,那么,我們繼承的限制似乎不是沒有道理的,因為在(非法)代碼,如class c virtual void f () & virtual async g () / body1 / virtual void f () & virtual async h() / body2 / class d : c override async g () / body3 / 一個會覆蓋g(),也有“一半”重寫f()。更務實的態(tài)度,消除對繼承的限制,使得這一切太容易引入無意僵局(或“異步泄漏”)。如

20、果上面的代碼是合法的,那么代碼編寫的期望,使匹配的c類的實例f()和g()的調用將無法工作時,通過d 所有的實例g()的調用會導致body3運行,所有的調用f()的僵局。請注意,在繼承的限制手段,如聲明virtual void f () & private async g () / body1 / 是不正確的聲明只是一個f()和g()是虛擬的,是沒有意義的(是作為我們的編譯器的錯誤標記),作為壓倒一切的要求其他要重寫了。這也是值得觀察,有一個傳遞閉包操作隱含在我們繼承的限制:如果f()是重寫,并加入與g(),然后因為g()必須被覆蓋,所以必須任何方法h()加入與g()等。 制定重寫規(guī)則更加復雜

21、和寬容是有可能的。我們的目前的規(guī)則有簡單的優(yōu)勢,但我們指的讀者富爾等。 2000為更深入的研究在繼承和并發(fā)加入演算。在該文件中,類(部分)同步的集合可以使用一些繼承運營商結合和轉化的模式。像往常一樣,然后創(chuàng)建對象可以實例化類,同步模式是不可擴展的。類的組成控制一個復雜的的打字紀律,防止“消息不理解為“在運行時的錯誤。格式良好上述條件2也是合理的,由現有的c#功能和純加入演算之間的潛在的不良相互作用。允許多個同步調用出現在一個單一的復調會給一種潛在的有用的交會設施(提供一個也加入語法允許特定的調用返回結果)。例如,以下的實例類: class rendezvous public int f (in

22、t i) & public int g (int j ) return j to f ;return i to g ;將匹配的雙f和g的調用,然后交換它們的值并繼續(xù)。然而,也必須決定在封鎖線程機構應運行,這樣的選擇一般觀察。如果這只因為線程的身份可以得到平等檢查,這個問題將是相當學術。但是,在c#,選擇線程做一個方案由于到折返鎖,基于堆棧的安全性和線程局部變量,從而使行為的顯著性差異“非?!狈墙粨Q。當然,這也不是很難明確方案復調c#上述交會:class rendezvous class thunk int wait() & async reply(int j ) return j ;publi

23、c int f (int i) thunk t = new thunk();af (i, t);return t.wait();private async af (int i, thunk t) & public int g (int j ) t . reply( j ); / returning to freturn i; / returning to g對于每個調用到f,我們創(chuàng)建了一個輔助類咚的實例,為了等待異步答復消息,這是同步后發(fā)送一些。3.3打字問題我們把async作為一個無效的亞型,并允許異步協(xié)變返回類型,只是在這兩個類型(偽)的情況下。從而 一個異步方法可以覆蓋一個void類型,

24、 委托void類型,可以創(chuàng)建一個異步方法, 一個異步方法可以實現一個接口void方法而不是相反。這種設計使得直觀的感覺(異步方法無效,但有額外的屬性返回“立即”),并最大限度地使用現有的c#代碼(父類,接口和兼容性委托的定義)的無效使用。4。復調c#的編程在介紹語言,我們現在怎么可能被用來解決并發(fā)編程問題的范圍。4.1一個簡單的細胞類我們先從一個簡單的地方細胞類的實現。單元格有兩種公共同步方法:void put(object o) 和 object get()。把呼叫塊,直到單元格是空的,然后用它的參數填充單元。一個調用獲取塊,直到單元格是滿的,然后刪除,并返回其內容:public class

25、 onecell public onecell() empty();public void put(object o) & private async empty() contains(o);public object get() & private async contains(object o) empty();return o; 在另外兩個公共方法,類使用兩個私人異步方法,empty()和contains(object o),進行單元格的狀態(tài)。有一個簡單的聲明構造和解釋兩個和弦這是如何工作:構造。當一個細胞被創(chuàng)建,它是最初是空的()。輸出和弦。如果我們把一個單元格是一個空的()對象,然后

26、單元格隨后包含(o)。獲取和弦。如果我們獲得()單元格的內容,然后包含一個空的對象,返回值是o。含蓄。在所有其他情況下,提出并獲取等待。使用私人異步方法(而不是域)的技術攜帶狀態(tài)是很常見的和弦的c。觀察到的構造建立,每在類onecell身體保留,簡單,易于驗證不變:總是有一個掛起的異步方法調用:無論是empty(),或contains(o)。(相反可能有任意數量的客戶端線程阻塞與掛起的調用,把獲取,甚至同時運行的語句返回0到之前的變量體。),因此也可以作為直接讀取類定義一個自動的規(guī)范:4.2讀寫鎖作為一個異步方法的使用進行狀態(tài)更現實的例子和同步訪問該狀態(tài)的和弦,我們現在考慮的經典問題多的讀者,

27、作家單鎖保護共享的易變的資源。每個客戶的要求,然后釋放,要么共享訪問或獨占訪問,使用相應的共享的公共方法,釋放共享,獨家,釋放獨占。沒有其他共享訪問塊的請求,直到客戶端具有獨占訪問,同時請求,直到沒有獨占訪問塊其他客戶端有任何訪問。一個典型的解決這個問題,使用傳統(tǒng)的并發(fā)原語在modula3給出由,比勒爾1989;和弦,它可以只有五和弦:class readerwriterreaderwriter() idle();public void shared() & async idle() s(1); public void shared() & async s(int n) s(n + 1); p

28、ublic void releaseshared() & async s(int n) if (n = 1) idle(); else s(n 1);public void exclusive() & async idle() public void releaseexclusive() idle(); 每一個版本如下規(guī)定相應的要求,不變是鎖狀態(tài)(沒有消息,一條消息空閑(),或單線程的種類和數量相匹配,目前消息小號n 0(n)持有該鎖(獨家線程,沒有線程,或n共享的線程)。萬一有一個消息,等候在一個給定的私有方法,它是一個選擇的問題,是否使用私有字段的對象或參數在私人訊息。在上面的例子中,n是

29、有關的,只有當有消息中的()。盡管如此,相反,我們可以編寫以下等效的代碼:class readerwriterprivate readerwriter() idle(); private int n = 0; / protected by s()public void shared() & async idle() n = 1; s(); public void shared() & async s() n+; s(); public void releaseshared() & async s() if (n = 0) idle(); else s();public void exclusi

30、ve() & async idle() public void releaseexclusive() idle(); 僅我們的執(zhí)行和底層操作系統(tǒng)調度提供基本的公平屬性例如:如果有足夠的等候和弦對象的調用匹配一個和弦,那么至少有一個和弦最終會運行。因此,它是非常有用的一些明確具體公平或優(yōu)先的額外的應用程序編程。例如,上面的代碼,編寫者未必能夠獲得新的讀者只要獨占鎖獲得一個共享鎖。我們進一步完善這個代碼來實現一個特定的公平當有掛起的編寫者,至少讀者和編寫者之間:一位編寫者,將獲得目前所有的讀者釋放它的鎖。為此,我們增加額外的共享狀態(tài):t(),我們不接受新的讀者,idleexclusive(),在我

31、們所提供的獨占鎖以前選擇主題:class readerwriterfair. . . / same content as in readerwriterprivate, plus:public void releaseshared() & async t() if (n = 0) idleexclusive(); else t();public void exclusive() & async s() t(); wait(); void wait() & async idleexclusive() 4.3合并異步消息消息傳遞通常會由服務器的外部接口,使用異步方法,每個參數都需要參數的請求和發(fā)送

32、請求已經服務的最終結果或通知的地方。例如,回調使用一個字符串參數,服務代表,并返回一個整數,看起來類似于:public delegate async intcallback(int result);public class service public async request(string arg, intcallback cb) int r ;. . . / do some workcb(r); / send the result back 一種常見的客戶端模式,然后涉及到幾個并發(fā)的異步請求后阻塞直到所有已完成。這可以編程如下:class join2 public intcallback

33、 rstcb;public intcallback secondcb;public join2() rstcb = new intcallback(rst);secondcb = new intcallback(second);public void wait(out int i, out int j )& async rst(int fst)& async second(int snd) i = fst; j = snd;class client public static void main(string args) service s1 = . . . ;service s2 = . .

34、 . ;join2 x = new join2();s1.request(args0, x . rstcb);s2.request(args1, x . secondcb);.int i, j ;x.wait(out i, out j ); .在到x.wait通話(i,j)將阻止,直到/除非服務已回答x上調用各自的回調。一旦發(fā)生這種情況,兩結果將被分配到i和j,客戶端將繼續(xù)進行。概括注冊(當然,自然屬于通用庫)任意同時通話,或定義類的條件,如等待至少35通話已完成很簡單的。附件2:外文原文modern concurrency abstractions for c#nick benton, lu

35、ca cardelli, and cedric fournetmicrosoft research1. introduction1.1languages and concurrencyconcurrency is an important factor in the behaviour and performance of modern code: concurrent programs are difcult to design, write, reason about, debug, and tune. concurrency can signicantly affect the mean

36、ing of virtually every other construct in the language (beginning with the atomicity of assignment), and can affect the ability to invoke libraries. despite this, most popular pro gramming languages treat concurrency not as a language feature, but as a collection of external libraries that are often

37、 underspecied. considerable attention has been given, after the fact, to the specication of important concurrency libraries birrell et al. 1987; gosling et al. 1996; detlefs et al. 1998; gurevich et al. 2000 to the point where one can usually determine what their behaviour should be under any implem

38、entation. yet, even when the concurrency libraries are satisfactorily specied, the simple fact that they are libraries, and not features of the language, has undesirable consequences. many features can be provided, in principle, either as language features or as libraries: typical examples are memor

39、y management and exceptions. the advantage of having such features “in the language” is that the compiler can analyze them, and can therefore produce better code and warn programmers of potential and actual problems. in particular, the compiler can check for syntactically embedded invariants that wo

40、uld be difcult to extract from a collection of library calls. moreover, programmers can more reliably state their intentions through a clear syntax, and tools other than the compiler can more easily determine the programmers intentions. domain specic languages ramming 1997; kamin 1997 are an extreme

41、 example of this linguistic approach: new adhoc languages are routinely proposed not to replace general purpose language, but to facilitate domain specic code analysis by the simple fact of expressing domain related features as primitive language constructs. we believe that concurrency should be a l

42、anguage feature and a part of language specications. serious attempts in this direction were made beginning in the 1970s with the concept of monitors hoare 1974 and the occam language inmos limited 1984 (based on communicating sequential processes hoare 1985). the general notion of monitors has beco

43、me very popular, particularly in its current object oriented form of threads and object bound mutexes, but it has been provided at most as a veneer of syntactic sugar for optionally locking objects on method calls. many things have changed in concurrency since monitors were introduced. communication

44、 has become more asynchronous, and concurrent computations have to be “orchestrated” on a larger scale. the concern is not as much with the efcient implementation and use of locks on a single processor or multiprocessor, but with the ability to handle asynchronous events without unnecessarily blocki

45、ng clients for long periods, and without deadlocking. in other words, the focus is shifting from shared memory concurrency to message or event oriented concurrency. these new requirements deserve programming constructs that can handle asynchronous communications well and that are not shackled to the

46、 shared memory approach. despite the development of a large collection of design pat terns lea 1999 and of many concurrent languages america 1989; agha et al. 1993; reppy 1992; pierce and turner 2000; philippsen 1995, only monitors have gained widespread acceptance as programming constructs. an inte

47、resting new linguistic approach has emerged recently with fournet and gonthiers 1996, 2002 join calculus, a process calculus well suited to direct implementation in a distributed setting. other languages, such as jocaml conchon and le fessant 1999 and funnel odersky 2000, combine similar ideas with

48、the functional programming model. here we propose an adapta tion of join calculus ideas to an object oriented language that has an existing thread sand locks concurrency model. itzstein and kearney 2001 have recently described very similar extensions for java. 1.2asynchronous programming asynchronou

49、s events and message passing are increasingly used at all levels of software systems. at the lowest level, device drivers have to respond promptly to asynchronous device events, while being parsimonious on resource use. at the graphical user interface level, code and programming models are notorious

50、ly complex because of the asynchronous nature of user events; at the same time, users hate being blocked unnecessarily. at the wide area network level, for example in collaborative applications, distributed workow, or web services, we are now experiencing similar problems and complexity because of t

51、he asynchronous nature and latencies of global communication. in all these areas, we naturally nd situations where there are many asynchronous messages to be handled concurrently, and where many threads are used to handle them. threads are still an expensive resource on most systems. however, if we

52、can somewhat hide the use of messages and threads behind a language mechanism, then many options become possible. a compiler may transform some patterns of concurrency into state machines, optimize the use of queues, use lightweight threads when possible, avoid forking threads when not necessary, an

53、d use thread pools. all this is really possible only if one has a handle on the spectrum of “things that can happen”: this handle can be given by a syntax for concurrent operations that can both hide and enable multiple implementation techniques. therefore, we aim to promote abstractions for asynchr

54、onous programming that are high level, from the point of view of a programmer, and that enable low level optimizations, from the point of view of a compiler and runtime systems. we propose an extension of the c# language with modern concurrency abstraction for asynchronous programming. in tune with

55、the musical spirit of c# and with the “orchestration” of concurrent activities, we call this language polyphonic c# .1 1.3c# and .net c# is a modern, type safe, object oriented programming language recently introduced by microsoft as part of visual studio.net ecma 2001. c# programs run on top of the

56、 .net framework, which includes a multilanguage execution engine and a rich collection of class libraries. the .net execution engine provides a multithreaded execution environment with synchronization based on locks potentially associated with each heapal located object. the c# language includes a l

57、ock statement, which obtains the mutex associated with a given object during the execution of a block. in addition, the .net libraries implement many traditional concurrency control primitives such as semaphores, mutexes and reader/writer locks, as well as an asynchronous programming model based on delegates.2 the .ne

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論