计算机毕业设计外文翻译--现代并发抽象c＃(编辑修改稿)

计算机毕业设计外文翻译--现代并发抽象c＃(编辑修改稿)内容摘要：

URNET Microsoft Research 1. INTRODUCTION Languages and Concurrency Concurrency is an important factor in the behaviour and performance of modern code: concurrent programs are difficult to design, write, reason about, debug, and tune. Concurrency can significantly affect the meaning 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 underspecified. Considerable attention has been given, after the fact, to the specification of important concurrency libraries [Birrell et al. 1987。 Gosling et al. 1996。 Detlefs et al. 1998。 Gurevich et al. 2020] to the point where one can usually determine what their behaviour should be under any Implementation. Yet, even when the concurrency libraries are satisfactorily specified, 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 memory management and exceptions. The advantage of having such features “in the language” is that the piler can analyze them, and can therefore produce better code and warn programmers of potential and actual problems. In particular, the piler can check for syntactically embedded invariants that would be difficult 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 piler can more easily determine the programmers‟ intentions. Domain Specific Languages [Ramming 1997。 Kamin 1997] are an extreme example of this linguistic approach: new adhoc languages are routinely proposed not to replace general purpose language, but to facilitate domain specific code analysis by the simple fact of expressing domain related features as primitive language constructs. We believe that concurrency should be a language feature and a part of language specifications. 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 bee 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 has bee more asynchronous, and concurrent putations have to be “orchestrated” on a larger scale. The concern is not as much with the efficient implementation 12 and use of locks on a single processor or multiprocessor, but with the ability to handle asynchronous events without unnecessarily blocking 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 munications well and that are not shackled to the 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 2020。 Philippsen 1995], only monitors have gained widespread acceptance as programming constructs. An interesting new linguistic approach has emerged recently with Four and Gonthier‟s [1996, 2020] 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 2020], bine similar ideas with 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 [2020] have recently described very similar extensions for Java. Asynchronous Programming Asynchronous 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 notoriously plex because of the asynchronous nature of user events。 at the same time, users hate being blocked unnecessarily. At the wide area work level, for example in collaborative applications, distributed workflow, or web services, we are now experiencing similar problems and plexity because of the asynchronous nature and latencies of global munication. In all these areas, we naturally find 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 can somewhat hide the use of messages and threads behind a language mechanism, then many options bee possible. A piler 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, and 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 asynchronous 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 piler and runtime systems. We propose an extension of the。