【導(dǎo)讀】在原則上，可以提供許多功能，，無論是作為語言特性或作為庫：典型的例子是，內(nèi)存管理和異常。的潛在和實(shí)際問題。理器，但沒有不必要的異步事件的處理能力阻止長期客戶，并沒有死鎖。存并發(fā)轉(zhuǎn)向消息或事件并發(fā)性。監(jiān)控器獲得廣泛接受的編程結(jié)構(gòu)。最近在富爾和Gonthier的[1996，2020]加入演算中顯現(xiàn)了一個有趣的新的語言方法，進(jìn)程演算非常。備事件迅速作出反應(yīng)，而資源利用上的吝嗇。在所有這些領(lǐng)域，我們自然會發(fā)現(xiàn)有很多要處理的同時異步消息的情況下，多線程用來處理它們。量級的線程，在可能的情況下，避免分叉線程沒有必要的，并使用線程池。因此，我們的目標(biāo)是促進(jìn)異步編程抽象是高層次的，從一個程序員的角度來看，使低層次的優(yōu)。音樂的精神調(diào)諧的C＃和并發(fā)活動的“協(xié)調(diào)流程”，我們稱這種語言復(fù)調(diào)C＃。.NETFramework中的并發(fā)和分配機(jī)制功能強(qiáng)大，但他們也不可否認(rèn)復(fù)雜。如果一個方法被聲明為異步調(diào)用任何保證立即基本上完成。他們使用async關(guān)鍵字，而不是宣布無效。

　　

【正文】 the body will be returned. The answer is that in any given chord, at most one method may be synchronous. If there is such a method, then the body runs in the thread associated with a call to that method, and the value is returned to that call. Only if there is no such method 3In a real implementation the nondeterminism in this very simple example may be resolved statically, so different executions will always produce the same result。 this is an allowable implementation. ACM Transactions on Programming Languages and Systems, Vol. 26, No. 5, September 2020 (. all the methods in the chord are asynchronous) does the body run in a new thread, and in that case there is no value to be returned. It should also be pointed out that the Buffer code, trivial though it is, is threadsafe. The locking that is required (for example to prevent the argument to a single Put being returned to two distinct Gets) is generated automatically by the piler. More precisely, deciding whether any chord is enabled by a call and, if so, removing the other pending calls from the queues and scheduling the body for execution, is an atomic operation. Apart from this atomicity guarantee, however, there is no monitor like mutual exclusion between chord bodies. Any mutual exclusion that is required must be explicitly programmed in terms of synchronization conditions in chord headers. The Buffer example uses a single chord to de?ne two methods. It is also possible (and mon) to have multiple chords involving a given method. For example: public class Buffer { public string Get() amp。 public async Put(string s) { return s。 } public string Get() amp。 public async Put(int n) { 15 return ()。 } } Now we have de?ned one method for getting data out of the buffer, but two methods for putting it in (which happen to be distinguished by type rather than name). A call to Get() can synchronize with a call to either of the Put() methods. If there are queued calls to both P ut()s, then which one synchronizes with a subsequent Get() is unspeci?ed. 3. INFORMAL SPECIFICATION Grammar The syntactic extensions to the C grammar [ECMA 2020, Appendix C] are very minor. We add a new keyword, async, and add it as an alternative return type: returntype : := type | void | async. This allows methods, delegates and interface methods to be declared asynchronous. In class member declarations, we replace method declaration with chord declaration: chorddeclaration : := Methodheader [amp。 methodheader]? body Methodheader : := attributes modi?ers returntype membername(formals). We call a chord declaration trivial if it declares a single, synchronous method (. it is a standard C method declaration). WellFormedness Extended classes are subject to a number of well formedness conditions: — Within a single methodheader: (1) If returntype is async then the formal parameter list formals may not contain any ref or out parameter — Within a single chorddeclaration: (2) At most one methodheader may have a nonasync returntype. (3) If the chord has a methodheader with returntype type, then body may use return statements with type expressions, otherwise body may use empty return statements. (4) All the formals appearing in methodheaders must have distinct identi?ers. (5) Two methodheaders may not have both the same member name and the same argument type signature. (6) The methodheaders must either all declare instance methods or all declare static methods. — Within a particular class: (7) All methodheaders with the same membername and argument type signature must have the same returntype and identical sets of attributes and modi?ers. (8) If it is a value class (struct), then only static methods may appear in nontrivial chords. (9) If any chorddeclaration includes a virtual method m with the override modi?er,5 then any method n that appears in a chord with m in the super class containing the overridden de?nition of m must also be overridden in the subclass. Most of these conditions are fairly straightforward, though Conditions 2 and 9 deserve some further ment. Condition 9 provides a conservative, but simple, sanity check when re?ning a 16 class that contains chords since, in general, implementation inheritance and concurrency do not mix well [Matsuoka and Yonezawa 1993] (see Four et al. [2020] for a discussion of “inheritance anomalies” in the context of the join calculus). Our approach here is to enforce a separation of these two concerns: a series of chords must be syntactically local to a class or a subclass declaration。 when methods are overridden, all their chords must also be pletely overridden. If one takes the view that the implementation of a given method consists of all the synchronization and bodies of all the chords in which it appears then our inheritance restriction seems not unreasonable, since in (illegal) 4Neither ref nor out parameters make sense for asynchronous messages, since they are both passed as addresses of locals in a stack frame that may have disappeared when the message is processed. 5In C , methods that are intended to be overridable in subclasses are explicitly marked as such by use of the virtual modi?er, while methods that are intended to override ones inherited from a superclass must explicitly say so with the override modi?er. code such as class C { virtual void f () amp。 virtual async g () { /? body1 ?/ } virtual void f () amp。 virtual async h() { /? body2 ?/ } } } class D : C { override async g () { /? body3 ?/ } one would, by overriding g (), have also ?half ? overridden f (). More pragmatically, removing the restriction on inheritance makes it all too easy to introduce inadvertent deadlock (or ?async leakage?). If the above code were legal, then code w