計(jì)算機(jī)畢業(yè)設(shè)計(jì)外文翻譯現(xiàn)代并發(fā)抽象C＃

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

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

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

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

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

6、能編程模型的想法。在這里，我們提出了一個(gè)加入演算想法的適應(yīng)一個(gè)面向?qū)ο蟮恼Z言，有一個(gè)現(xiàn)有線程和鎖的并發(fā)模型。 itzstein和kearney 2001最近為java描述非常類似的擴(kuò)展。1.2異步編程異步的事件和消息傳遞越來越多地用于在各級(jí)軟件系統(tǒng)。在最低水平，設(shè)備驅(qū)動(dòng)程序必須對(duì)異步設(shè)備事件迅速作出反應(yīng)，而資源利用上的吝嗇。在圖形用戶界面級(jí)別是出了名的，復(fù)雜的代碼和編程模型，因?yàn)橛脩羰录漠惒叫再|(zhì);在同一時(shí)間，用戶討厭被不必要的封鎖。在廣域網(wǎng)的水平，例如，在協(xié)作應(yīng)用，分布式的工作流，web服務(wù)，我們現(xiàn)在遇到類似的問題，因?yàn)槿蛲ㄐ诺漠惒叫再|(zhì)和潛伏期和復(fù)雜性。在所有這些領(lǐng)域，我們自然會(huì)發(fā)現(xiàn)有很多

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

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

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

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

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

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

13、t()再有就是現(xiàn)在的一次匹配，所以掛起調(diào)用出列和其相關(guān)阻塞的線程是喚醒運(yùn)行的復(fù)調(diào)，返回值給s。 如果沒有掛起調(diào)用的buff.get（），然后調(diào)用到buff . put(s)僅僅是排隊(duì)，直到一個(gè)個(gè)到達(dá)。到底哪的電話匹配是不確定的，所以即使是單線程程序如：buffer buff = new buffer();buff . put(“blue”);buff . put(“sky”);console.write(buff . get() + buff . get();也是不確定的（印刷或者“藍(lán)天”或“天藍(lán)”）。請(qǐng)注意，執(zhí)行緩沖不涉及產(chǎn)生任何主題：復(fù)調(diào)本身在運(yùn)行時(shí)，它在一個(gè)已經(jīng)存在的線程（即一個(gè)名為ge

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

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

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

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

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

19、聲明的語法;方法重寫時(shí)，他們所有的復(fù)調(diào)還必須完全重寫。如果認(rèn)為執(zhí)行一個(gè)給定的方法包括所有同步和機(jī)構(gòu)，它出現(xiàn)的所有的復(fù)調(diào)，那么，我們繼承的限制似乎不是沒有道理的，因?yàn)樵冢ǚ欠ǎ┐a，如class c virtual void f () & virtual async g () / body1 / virtual void f () & virtual async h() / body2 / class d : c override async g () / body3 / 一個(gè)會(huì)覆蓋g（），也有“一半”重寫f（）。更務(wù)實(shí)的態(tài)度，消除對(duì)繼承的限制，使得這一切太容易引入無意僵局（或“異步泄漏”）。如

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

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

22、t i) & public int g (int j ) return j to f ;return i to g ;將匹配的雙f和g的調(diào)用，然后交換它們的值并繼續(xù)。然而，也必須決定在封鎖線程機(jī)構(gòu)應(yīng)運(yùn)行，這樣的選擇一般觀察。如果這只因?yàn)榫€程的身份可以得到平等檢查，這個(gè)問題將是相當(dāng)學(xué)術(shù)。但是，在c#，選擇線程做一個(gè)方案由于到折返鎖，基于堆棧的安全性和線程局部變量，從而使行為的顯著性差異“非?！狈墙粨Q。當(dāng)然，這也不是很難明確方案復(fù)調(diào)c#上述交會(huì)：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對(duì)于每個(gè)調(diào)用到f，我們創(chuàng)建了一個(gè)輔助類咚的實(shí)例，為了等待異步答復(fù)消息，這是同步后發(fā)送一些。3.3打字問題我們把a(bǔ)sync作為一個(gè)無效的亞型，并允許異步協(xié)變返回類型，只是在這兩個(gè)類型（偽）的情況下。從而 一個(gè)異步方法可以覆蓋一個(gè)void類型，

24、 委托void類型，可以創(chuàng)建一個(gè)異步方法， 一個(gè)異步方法可以實(shí)現(xiàn)一個(gè)接口void方法而不是相反。這種設(shè)計(jì)使得直觀的感覺（異步方法無效，但有額外的屬性返回“立即”），并最大限度地使用現(xiàn)有的c#代碼（父類，接口和兼容性委托的定義）的無效使用。4。復(fù)調(diào)c#的編程在介紹語言，我們現(xiàn)在怎么可能被用來解決并發(fā)編程問題的范圍。4.1一個(gè)簡(jiǎn)單的細(xì)胞類我們先從一個(gè)簡(jiǎn)單的地方細(xì)胞類的實(shí)現(xiàn)。單元格有兩種公共同步方法：void put(object o) 和 object get()。把呼叫塊，直到單元格是空的，然后用它的參數(shù)填充單元。一個(gè)調(diào)用獲取塊，直到單元格是滿的，然后刪除，并返回其內(nèi)容：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; 在另外兩個(gè)公共方法，類使用兩個(gè)私人異步方法，empty()和contains(object o)，進(jìn)行單元格的狀態(tài)。有一個(gè)簡(jiǎn)單的聲明構(gòu)造和解釋兩個(gè)和弦這是如何工作：構(gòu)造。當(dāng)一個(gè)細(xì)胞被創(chuàng)建，它是最初是空的（）。輸出和弦。如果我們把一個(gè)單元格是一個(gè)空的（）對(duì)象，然后

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

27、作家單鎖保護(hù)共享的易變的資源。每個(gè)客戶的要求，然后釋放，要么共享訪問或獨(dú)占訪問，使用相應(yīng)的共享的公共方法，釋放共享，獨(dú)家，釋放獨(dú)占。沒有其他共享訪問塊的請(qǐng)求，直到客戶端具有獨(dú)占訪問，同時(shí)請(qǐng)求，直到?jīng)]有獨(dú)占訪問塊其他客戶端有任何訪問。一個(gè)典型的解決這個(gè)問題，使用傳統(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(); 每一個(gè)版本如下規(guī)定相應(yīng)的要求，不變是鎖狀態(tài)（沒有消息，一條消息空閑（），或單線程的種類和數(shù)量相匹配，目前消息小號(hào)n 0（n）持有該鎖（獨(dú)家線程，沒有線程，或n共享的線程）。萬一有一個(gè)消息，等候在一個(gè)給定的私有方法，它是一個(gè)選擇的問題，是否使用私有字段的對(duì)象或參數(shù)在私人訊息。在上面的例子中，n是

29、有關(guān)的，只有當(dāng)有消息中的（）。盡管如此，相反，我們可以編寫以下等效的代碼：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)調(diào)度提供基本的公平屬性例如：如果有足夠的等候和弦對(duì)象的調(diào)用匹配一個(gè)和弦，那么至少有一個(gè)和弦最終會(huì)運(yùn)行。因此，它是非常有用的一些明確具體公平或優(yōu)先的額外的應(yīng)用程序編程。例如，上面的代碼，編寫者未必能夠獲得新的讀者只要獨(dú)占鎖獲得一個(gè)共享鎖。我們進(jìn)一步完善這個(gè)代碼來實(shí)現(xiàn)一個(gè)特定的公平當(dāng)有掛起的編寫者，至少讀者和編寫者之間：一位編寫者，將獲得目前所有的讀者釋放它的鎖。為此，我們?cè)黾宇~外的共享狀態(tài)：t（），我們不接受新的讀者，idleexclusive（），在我

31、們所提供的獨(dú)占鎖以前選擇主題：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合并異步消息消息傳遞通常會(huì)由服務(wù)器的外部接口，使用異步方法，每個(gè)參數(shù)都需要參數(shù)的請(qǐng)求和發(fā)送

32、請(qǐng)求已經(jīng)服務(wù)的最終結(jié)果或通知的地方。例如，回調(diào)使用一個(gè)字符串參數(shù)，服務(wù)代表，并返回一個(gè)整數(shù)，看起來類似于：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 一種常見的客戶端模式，然后涉及到幾個(gè)并發(fā)的異步請(qǐng)求后阻塞直到所有已完成。這可以編程如下：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）將阻止，直到/除非服務(wù)已回答x上調(diào)用各自的回調(diào)。一旦發(fā)生這種情況，兩結(jié)果將被分配到i和j，客戶端將繼續(xù)進(jìn)行。概括注冊(cè)（當(dāng)然，自然屬于通用庫）任意同時(shí)通話，或定義類的條件，如等待至少35通話已完成很簡(jiǎn)單的。附件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