📄 http:^^www.cs.utexas.edu^users^psp^seuss-overview.html
字号:
MIME-Version: 1.0
Server: CERN/3.0
Date: Tuesday, 07-Jan-97 15:47:07 GMT
Content-Type: text/html
Content-Length: 5655
Last-Modified: Friday, 12-Apr-96 15:11:20 GMT
<HTML><HEAD><TITLE>Overview of Seuss</TITLE></HEAD><center><H2>Overview of Seuss</H2></center><HR>We are currently working on a project, called <b>Seuss</b>. Theresearch proposed in Seuss is based on two observations: (1) theapplications that will be implemented on networks of processors in thefuture will be significantly more ambitious than the currentapplications (which are mostly involved with transmissions of digitaldata and images), and (2) many of the programming concepts developedfor databases, object-oriented programming and designs of reactivesystems can be unified into a concise model of distributed programsthat can serve as the foundation for designing these futureapplications.<p>Research in multiprogramming has, traditionally, attempted toreconcile two apparently contradictory goals: (1) it should bepossible to understand a module (e.g., a process or a data object) inisolation, without considerations of interference by the othermodules, and (2) it should be possible to implement concurrent threadsat a fine level of granularity so that no process is ever locked outof accessing common data for long periods of time. The goals arein conflict because fine granularity, in general, impliesconsiderable interference. The earliest multiprograms (see, forinstance, the solution to the mutual exclusion problem in Dijkstra<a href="#ewd">[0]</a>)were trivially small and impossibly difficult tounderstand, because the behaviors of the individual processes couldnot be understood in isolation, and all possible interactions amongthe processes had to be analyzed explicitly. Since then, much efforthas gone into limiting or even eliminating interference amongprocesses by employing a variety of synchronization mechanisms: locksor semaphores, critical regions, monitors and message communications.<p>Constraining the programming model to a specific protocol (binarysemaphores or message communication over bounded channels, forinstance) will prove to be short-sighted in designing complexapplications. More general mechanisms for interactions among modules,that include these specific protocols, are required. Further, for thedistributed applications of the future, it is essential to devise amodel in which the distinction between computation and communicationis removed; in particular, the methods for designing and reasoningabout the interfaces should be no different from those employed forthe computations at the nodes of the network.<p>Seuss fosters a discipline of programming that makes itpossible to understand a program execution as a single thread ofcontrol, yet it permits program implementation through multiplethreads. As a consequence, it is possible to reason about theproperties of a program from its single execution thread, whereas animplementation on a specific platform (e.g., shared memory or messagecommunicating system) may exploit the inherent concurrencyappropriately. A central theorem establishes that multiple executionthreads implement single execution threads, i.e., any property provenfor the latter is a property of the former as well.<p>A major point of departure in Seuss is that there is no built-inconcurrency and no commitment to either shared memory ormessage-passing style of implementation. No specific communication orsynchronization mechanism, except the procedure call, is built into themodel. In particular, the notions of input/output and theircomplementary nature in rendezvous-based communication(<a href="#csp">[1]</a> , <a href="#ccs">[2]</a>)are outside this model. There is no distinction between computation andcommunication; process specifications and interface specifications arenot distinguished. Consequently, we do not have many of thetraditional multiprogramming concepts such as, processes, locking,rendezvous, waiting, interference and deadlock, as basic concepts inour model. Yet, typical multiprograms employing message passing overbounded or unbounded channels can be encoded in Seuss by declaring theprocesses and channels as the components of a program; similarly,shared memory multiprograms can be encoded by having processes andmemories as components. Seuss permits a mixture of either style ofprogramming, and a variety of different interaction mechanisms --semaphore, critical region, 4-phase handshake, etc. -- can be encodedas components.<p>Seuss proposes a complete disentanglement of the sequential andconcurrent aspects of programming. We expect large sections of codeto be written, understood and reasoned-about as sequentialprograms. <em>We view multiprogramming as a way to orchestrate theexecutions of these sequential programs, by specifying the conditionsunder which each program is to be executed</em>. Typically, severalsequential programs will execute simultaneously; yet, we can guaranteethat their executions are non-interfering, and hence, each program maybe regarded as atomic. We propose an efficient implementation schemethat can, using user directives, interleave the individual sequentialprograms with fine granularity without causing any interference.<HR><H4>References</H4><A NAME=ewd>[0]</A> E.W.Dijkstra. Solution of a Problem in ConcurrentProgramming Control. <em>Communications of the ACM</em>, 8(9):569,1965. <br><A NAME=csp>[1]</A> C.A.R.Hoare. <em>Communicating SequentialProcesses.</em> Prentice Hall International, London, 1984. <br><A NAME=ccs>[2]</A> R. Milner. <em>Communication and Concurrency.</em>International Series in Computer Science, C.A.R.Hoare, Series Editor.Prentice-Hall International, London, 1989.</BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -