【正文】 布無效。復(fù)調(diào) C＃中，如果一個(gè)方法被聲明為異步調(diào)用任何保證立即基本上完成。 異步方法。復(fù)調(diào) C＃語言概述 本節(jié)介紹新構(gòu)造復(fù)調(diào)的 C＃語法和語義，然后給出了更精確，雖然仍是非正式的，規(guī)范 語法。因此， C＃中似乎是一個(gè)為主流的并發(fā)語 言支持我們的想法，理想的測(cè)試床語言。 .NET Framework 中的并發(fā)和分配機(jī)制功能強(qiáng)大，但他們也不可否認(rèn)復(fù)雜。此外， .NET 庫實(shí)現(xiàn)了許多傳統(tǒng)的并發(fā)控制原語，如信號(hào)量，互斥和讀 /寫鎖，以及異步編程模型的基礎(chǔ)上代表。 .NET 執(zhí)行引擎提供了一個(gè)多線程的執(zhí)行環(huán)境潛在的相互關(guān)聯(lián)與同步鎖MENT 在堆上分配的對(duì)象。 C 和 .NET C＃是一個(gè)現(xiàn)代，類型安全，面向?qū)ο缶幊陶Z言，最近微軟推出的 Visual ][ECMA 的一部分。我們提出用現(xiàn)代并發(fā) C＃語言的 延伸異步編程抽象。這一切都是真的有可能只有一個(gè)擁有上譜“，可以發(fā)生的事情”：這個(gè)手柄可以處理由并發(fā)操作，既可以隱藏，從而使多個(gè)語法實(shí)現(xiàn)技術(shù)。然而，如果我們能有些隱藏在背后的消息和線程使用一種語言機(jī)制，那么很多的選項(xiàng)成為可能。 在所有這些領(lǐng)域，我們自然會(huì)發(fā)現(xiàn)有很多要處理的同時(shí)異步消息的情況下，多線程用來處理它們。在同一時(shí)間，用戶討厭被不必要的封鎖。在最低水平，設(shè)備驅(qū)動(dòng)程序必須對(duì)異步設(shè)備事件迅速作出反應(yīng)，而資源利用上的吝嗇。 itzstein 和 Kearney [2020]最近為 Java 描述非常類似的擴(kuò)展。其他語言，如 JoCaml [Conchon and Le Fessant 1999]和 Funnel [Odersky 4 2020]，結(jié)合了類似功能編程模型的想法。 Philippsen 1995]，但只有監(jiān)控器獲得廣泛接受的編程結(jié)構(gòu)。 Reppy 1992。盡管出現(xiàn)大規(guī)模的模式設(shè)計(jì)如 [America 1989。換句話說，重心正在從共享內(nèi)存并發(fā)轉(zhuǎn)向消息或事件并發(fā)性。通信已變得更加的異步，并行計(jì)算一定要通過規(guī)模較大的“精心策劃”的。監(jiān)控器的一般概念已經(jīng)變得非常流行，特別是在其目前的面向?qū)ο蟮男问骄€程和對(duì)象綁定互斥，但它已提供作為一個(gè)語法的外殼模板，最可選鎖定對(duì)象上的方法調(diào)用。 我們相信，并發(fā)應(yīng)該是一個(gè)語言功能的一部分和一種語言規(guī)范。特定領(lǐng)域的語言 [Ramming 1997。特別是，編譯器可以檢查語法嵌入的變量，這將是很難從庫中提取調(diào)用的集合。 在原則上，可以提供許多功能，無論是作為語言特性或作為庫：典型的例子是，內(nèi)存管理和異常。 2020] 已給予相當(dāng)?shù)闹匾?，通常通過這些規(guī)范就可以對(duì)他們的行為應(yīng)該在何處執(zhí)行做出判斷。 1996 年 Detlefs 等。 1987 年 。盡管這樣，最流行的編程語言對(duì)待并發(fā)語言不是作為一種語言功能的并發(fā)性，而往往是作為一個(gè)收集的，根據(jù)指定的外部庫。卡戴爾和塞德里克?富爾 微軟研究院 語言和并發(fā) 并發(fā)是現(xiàn)代代碼中的一個(gè)重要實(shí)現(xiàn)形式：并發(fā)程序的編寫設(shè)計(jì)，解釋，調(diào)試，和調(diào)整都是有難度的。 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 2020 附件： ； 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)教師簽名： 年 月 日 3 附件 1：外文資料翻譯譯文 現(xiàn)代并發(fā)抽象 C＃ 尼克本頓，盧卡并發(fā)可以顯著影響一個(gè)結(jié)構(gòu)中的語言的含義（開始轉(zhuǎn)讓的原子），并能影響調(diào)用庫的能力?？紤]到這樣的事實(shí)后，規(guī)范的并發(fā)庫 [比勒爾等。斯林等。 1998年古列維奇等。然而，即使當(dāng)并發(fā)庫被正 確指定，但由于他們是庫，而不是語言的特點(diǎn)這個(gè)事實(shí)，還是會(huì)有不良的后果。有“語言”等功能的優(yōu)點(diǎn)是，編輯者可以對(duì)它們進(jìn)行分析，因此可以產(chǎn)生更好的代碼，并警告親程序員的潛在和實(shí)際問題。此外，程序員可以更可靠說明自己的意圖，通過一個(gè)清晰的語法和其他工具比編輯者可以更容易地確定程序員的意圖。 Kamin 1997]是一 個(gè)極端的語言學(xué)方法的例子：經(jīng)常提出新的特設(shè)語言并不是要取代通用的語言，而是為了方便特定于域的代碼分析域相關(guān)的功能，作為原始的語言表達(dá)簡(jiǎn)單的事實(shí)結(jié)構(gòu)。在 70 年代開始在這個(gè)方向作了很多嘗試，顯示器 [霍爾 1974年 ]的概念和奧卡姆語言 [INMOS有限公司 1984]（基于通信順序進(jìn)程 [霍爾 1985]）。 許多事情因 為監(jiān)控器被引入并發(fā)而已經(jīng)改變。值得關(guān)注的是沒有那么多的有效的實(shí)施和使用鎖在一個(gè)單一的處理器或者多重處理器，但沒有不必要的異步事件的處理能力阻止長(zhǎng)期客戶，并沒有死鎖。 這些新的要求應(yīng)該得到可以處理異步通信和不束縛共享記憶的編程結(jié)構(gòu)的方法。 Agha et 。 Pierce and Turner 2020。 最近在富爾和 Gonthier 的 [1996， 2020]加入演算中顯現(xiàn)了一個(gè)有趣的新的語言方法，進(jìn)程演算非常適合在分布式的環(huán)境中直接執(zhí)行。在這里，我們提出了一個(gè)加入演算想法的適應(yīng)一個(gè)面向?qū)ο蟮恼Z言，有一個(gè)現(xiàn)有線程和鎖的并發(fā)模型。 異步編程 異步的事件和消息傳遞越來越多地用于在各級(jí)軟件系統(tǒng)。在圖形用戶界面級(jí)別是出了名的，復(fù)雜的代碼和編程模型，因?yàn)橛脩羰录漠惒叫再|(zhì) 。在廣域網(wǎng)的水平，例如，在協(xié)作應(yīng)用，分布式的工作流， Web 服務(wù)，我們現(xiàn)在遇到類似的問題，因?yàn)槿蛲ㄐ诺漠惒叫再|(zhì)和潛伏期和復(fù)雜性。主題仍 然是一個(gè)在大多數(shù)系統(tǒng)中昂貴的資源。編譯器可狀態(tài)機(jī)轉(zhuǎn)換成并發(fā)的一些模式，優(yōu)化使用隊(duì)列，使用輕量級(jí)的線程，在可能的情況下，避免分叉線程沒有必要的，并使用線程池。因此，我們的目標(biāo)是促進(jìn)異步編程抽象是高層次的，從一個(gè)程序員的角度來看，使低層次的優(yōu)化，從一個(gè)編譯器和運(yùn)行時(shí)系統(tǒng)的角度來看。在與音樂的精神調(diào)諧的 C＃和并發(fā)活動(dòng)的“協(xié)調(diào)流程”，我們稱這種語言復(fù)調(diào) C＃。 C＃程序上運(yùn)行 .NET 框架，其中包括多語言的執(zhí)行頂部 引擎和一個(gè)豐富的類庫集合。 C＃語言，包括一個(gè) lock 語句，執(zhí)行的過程中獲得一個(gè)給定的對(duì)象相關(guān)聯(lián)的互斥阻塞。 .NET 框架還提供更高級(jí)別的基礎(chǔ)設(shè)施建設(shè)分布應(yīng)用和服務(wù)，如基于 SOAP 的消息傳遞和遠(yuǎn)程方法打電話。且不說從原語，更多的或較少的基礎(chǔ)設(shè)施，在烤“讓人眼花繚亂，有一臺(tái)機(jī)器上（共享內(nèi)存，線程，同步的基礎(chǔ)上的東西是 20世紀(jì) 70 年代的并發(fā)模型之間的不匹配相互排斥）和異步，基于消息的風(fēng)格，使用編程基于網(wǎng)絡(luò)的應(yīng)用和服務(wù)。 2。 基本思路 到 C＃的相當(dāng)傳統(tǒng)的面向?qū)ο缶幊棠Ｐ?，?fù)調(diào) C＃增加了兩個(gè)新概念：異步方法和復(fù)調(diào)。傳統(tǒng)的方法是同步的，在檢測(cè)到來電者沒有取得任何進(jìn)展，直到被叫方完成。異步方法永遠(yuǎn)不會(huì)返回結(jié)果（或拋出異常） 。調(diào)用異步方法很像是發(fā)送消息，或張貼的 事件。然而，這樣的定義，實(shí)際上是相當(dāng)難得的 C＃復(fù)調(diào)。復(fù)調(diào)。頭是一套方法聲明由“＆”分隔?？紤]，例如 : public class Buffer { public string Get() amp。 } } 上面的代碼定義了兩個(gè)實(shí)例方法的類的緩沖區(qū)，這是共同定義在一個(gè)單一的復(fù)調(diào)。 async Put(string s)方法是異步的（沒有返回結(jié)果），并接受一個(gè)字符 串參數(shù)。然后有兩種可能性： 如果有以前的未匹配過的的通話 buff . Put(s) (for some string s)，那么現(xiàn)在有一個(gè)比賽，所以離隊(duì)待沽 Put(s)和復(fù)調(diào)的身體運(yùn)行，返回到呼叫者的 buff . Get()方法。 相反，在調(diào)用異步方法的 buff . Put(.)，來電從未等待，但 對(duì)于其他線程可能有兩種行為： 如果有以前的未匹配過的通話 buff . Get()再有就是現(xiàn)在的一次匹配，所以掛起調(diào)用出列和其相關(guān)阻塞的線程是喚醒運(yùn)行的復(fù)調(diào)，返回值給 s。 到底哪的電話匹配是不確定的，所以即使是單線程程序如： Buffer buff = new Buffer()。 buff . Put(“sky”)。 也是不確定的（印刷或者“藍(lán)天”或“天藍(lán)”）。讀者在這一點(diǎn)上可能會(huì)想什么規(guī)則決定在哪個(gè)線程體運(yùn)行，或如何，我們知道，方法調(diào)用將返回人體所計(jì)算的最終價(jià)值。如果有這種方法，然后身體在與調(diào)用線程運(yùn)行這一號(hào)召的方法，并返回值。還應(yīng)當(dāng)指出，緩沖區(qū)的代碼，瑣碎，但它是，是線程安全的。更確切地說，決定是否任何復(fù)調(diào)呼叫啟用，如果是這樣，從隊(duì)列中刪除其他懸而未決的呼叫和調(diào)度為執(zhí)行機(jī)構(gòu)，是一個(gè)原子操作。任何相互排斥的需要，必須明確在編程在弦頭的同步條件。這也是（普通）有涉及給定方法的多復(fù)調(diào)。 public async Put(string s) { return s。 public async Put(int n) { return ()。 Get()調(diào)用可以同步調(diào)用的 put（）方法。 3。我們添加一個(gè)新的關(guān)鍵字 async，并添加它作為一種替代的返回類型： returntype : := type | void | async 這使得方法，代表和接口方法被宣布異步的。 methodheader]? body methodheader : := 屬性修飾符返回類型成員名（形參）。 良好的格式 擴(kuò)展類是格式良好的條件： 在一個(gè)單一的方法頭： （ 1）如果返回類型是異步的，那么正式的參數(shù)列表中的形參不得 包含任何 ref 或 out 參數(shù)修飾符。 （ 3）如果弦有一個(gè)返回類型的類型的方法頭，然后身體可能使用返回類型的表達(dá)式的語句，否則身體可能使用空的 return 語句。 （ 5）兩種方法，頭可能沒有相同 的成員名稱和相同的參數(shù)類型簽名。 在一個(gè)特定的類： （ 7）具有相同的成員名稱和參數(shù)類型的所有方法頭簽名必須具有相同的屬性的返回類型和相同的套和修飾符。 （ 9）如果任何復(fù)調(diào)聲明包括一個(gè)覆蓋虛擬方法 M 修飾符，那么任何方法 n 出現(xiàn)在包含重寫定義的 m 的超弦與 M 也必須被重寫在子類中。 條件 9 提供了一個(gè)保守的，但簡(jiǎn)單，完整 性檢查時(shí)，煉油類包含復(fù)調(diào)以來，在一般情況下，實(shí)現(xiàn)繼承和并發(fā)不拌勻 [松岡和米澤 1993]（見富爾等。這里是我們的方法來執(zhí)行這兩個(gè)關(guān)注點(diǎn)分離：一系列的復(fù)調(diào)，必須是當(dāng)?shù)氐囊活惢蜃宇惵暶鞯恼Z法 。如果認(rèn)為執(zhí)行一個(gè)給定的方法包括所有同步和機(jī)構(gòu)，它出現(xiàn)的所有的復(fù)調(diào)，那么，我們繼承的限制似乎不是沒有道理的，因?yàn)樵冢ǚ欠ǎ┐a，如 class C { 7 virtual void f () amp。 virtual async h() { /? body2 ?/ } } } class D : C { override async g () { /? body3 ?/ } 一個(gè)會(huì)覆蓋 G（），也有“一半”重寫 F（）。如果上面的代碼是合法的，那么代碼編寫的期望，使匹配的 C 類的實(shí)例 F（）和 g（）的調(diào)用將無法工作時(shí)，通過 D 所有的實(shí)例 g（）的調(diào)用會(huì)導(dǎo)致 body3 運(yùn)行，所有的調(diào)用 f（）的僵局。 private async g () { /? body1 ?/ } 是不正確的聲明只是一個(gè) F（）和 g（）是虛擬的，是沒有意義的（是作為我們的編譯器的錯(cuò)誤標(biāo)記），作為壓倒一切的要求其他要重寫了。 制定重寫規(guī)則更加復(fù)雜和寬容是有可能的。 [2020]為更深入的研究在繼承和并發(fā)加入演算。像往常一樣，然后創(chuàng)建對(duì)象可以實(shí)例化類，同步模式是不可擴(kuò)展的。格式良好上述條件 2也是合理的，由現(xiàn)有的 C功能和純加入演算之間的潛在的不良相互作用。例如，以下的實(shí)例類： class RendezVous { public int f (int i) amp。 return i to g 。然而，也必須決定在封鎖線程機(jī)構(gòu)應(yīng)運(yùn)行，這樣的選擇一般觀察。但是，在C，選擇線程做一個(gè)方案由于到折返鎖，基于堆棧的安全性和線程局部變量，從而使行為的顯著性差異“非?！狈墙粨Q。 async reply(int j ) {return j 。 af (i, t)。 } private async af (int i, Thunk t) amp。 // returning to f 8 return i。 打字問題 我們把 async 作為一個(gè)無效的亞型，并允許異步協(xié)變返回類型，只是在這兩個(gè)類型（偽）的情況下。這種設(shè)計(jì)使得直觀的感覺（異步方法無效，但有額外的屬性返回“立即”），并最大限度地使用現(xiàn)有的 C代碼（父類，接口和兼容性委托的定義）的無效使用。復(fù)調(diào) c的編程 在介紹語言，我們現(xiàn)在怎么可能被用來解決并發(fā)編程問題的范圍。單元格有兩種公共同步方法： void Put(object o) 和 object Get()。一個(gè)調(diào)用獲取塊，直到