DIJKSTRA, E. W. The structure of the "THE"-multiprogramming system. Commun. ACM 11, 5 (1968), 341--346.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....layer 0 can be regarded as a transformation of the given machine into one that is more attractive for the formulation of the subroutines of layer 1. Similarly the software of our multiprogramming system can be regarded as structured in layers. We conceive an ordered sequence of machines: A[0] A[ 1] . A[n] where A[0] is the given hardware machine and where the software of layer i transforms machine A[i] into A[i l] The software of layer i is defined in terms of machine A[i] it is to be executed by machine A[i] the software of layer i uses machine A[i] to make machine A[i l] Compared ....

.... software of layer i will use some of the resources of machine A[i] to provide resources for machine A[i 1] in machine A[i 1] and higher these used resources of machine A[i] must be regarded as no longer there The explicit introduction (and functional description ) of the intermediate machines A[1] through A[n 1] has been more than more word play: it has safeguarded us against much confusion as is usually generated by a set of tacit assumptions. Phrasing the structure of our total task as the design of an ordered sequence of machines provided us with a useful framework in marking the ....

[Article contains additional citation context not shown here]

Dijkstra E.W., The Structure of the 'T.H.E.'Multiprogramming System. Comm. ACM 11, 5 (1968) pp. 341-346.

....a year and now comprises eight integrated end user services [8] It is available to everyone at UC San Diego, and is in active use by our extended group. We are now in the process of deploying ActiveCampus to our base of 700 HP Jornada users. Our experiments with a traditional layered approach [5] combined with a hybrid of the mediator and observer design patterns [15] yielded significant leverage. However, maintaining a high level of integration and performance while maintaining a decoupling of services from modeled entities and from each other required additional architectural ....

....in Figure 3. 4.1 Early Design Experience Context aware computing, especially in a multi application setting, is both representationally and behaviorally complex. To address these challenges, we settled on a layered design to incrementally provide behavior and assert systemwide properties [5]. The principal layers were, bottom up: Data Storage (i.e. the database) Data Abstraction (e.g. sensor data and entity objects) Object Correlation (e.g. mapping raw sensor data to internal forms, as well as services themselves) and Environment Proxy (i.e. transport to external devices) To ....

E. W. Dijkstra. The structure of the "THE"- multiprogramming system. Communications of the ACM, 11(5):341--346, May 1968.

....These business requirements are not the business functions, but rather the functional and non functional requirements of a system to support the business functions. STRUCTURE MATTERS From the beginnings of software engineering, structure has been the foundation of good architecture [Parn72] [Dijk68]. There are some basic tenets that can be used to guide the architecture centered deployment [Clem96] n Systems can be built in a rapid, cost effective manner by importing (or generating) large externally developed components. n It is possible to predict certain qualities about a system by ....

"The Structure of the T.H.E. Multiprogramming System," E. W. Dijkstra, Communications of the ACM, 26(1), January, 1968, pp. 49--52.

....in greater detail in Chapter 3. 2.1.4 CLU CLU is a sequential, object oriented programming language designed to facilitate the construction of high quality programs through the use of abstraction [Liskov 77] The concept of levels of abstraction was introduced by Dijkstra in the T.H.E. system [Dijkstra 68] and integrated into the object model in collaboration with Hoare and Dahl [Dahl 72] The designers of CLU built upon this and related work in abstraction and type extensibility in programming languages [Wulf 74b, Ingalls 78, Xerox 79, Parnas 78, Morris, Jr. 73] CLU has had significant influence ....

E. W. Dijkstra. The Structure of the "THE" Multiprogramming System. Communications of the ACM, 11(5):341--346, May 1968.

....business functions, but rather the functional and non functional requirements of a system to support the business functions. Niwot Ridge Consulting, September 2000 10 STRUCTURE MATTERS From the beginnings of software engineering, structure has been the foundation of good architecture [Parn72] [Dijk68]. There are some basic tenets that can be used to guide the architecture centered deployment [Clem96] n Systems can be built in a rapid, cost effective manner by importing (or generating) large externally developed components. n It is possible to predict certain qualities about a system by ....

"The Structure of the T.H.E. Multiprogramming System," E. W. Dijkstra, Communications of the ACM, 26(1), January, 1968, pp. 49--52.

....as such within their organiza 1 To be sure, there were some notable exceptions. Parnas recognized the importance of system families [33] and architectural decomposition principles based on information hiding [34] Others, such as Dijkstra, exposed certain system structuring principles [12]. Code Figure 1: Software Architecture as a Bridge Requirements Software Architecture tions learned their craft by hard experience in particular domains, and were unable to teach others what they knew. It was usually impossible to analyze an architectural description for consistency or to ....

E. W. Dijkstra. The structure of the "THE" -- multiprogramming system. Communications of the ACM, 11(5):341-346, 1968.

....The analysis process soon became unmanageable because we had too many objects to deal with. The problem of subsystem object distinction was relevant in the distributed operating system design assignment. Typically in operating systems, resources are encapsulated within each other like onion rings [47]. In case concurrent resources are encapsulated within each other, it is likely that subsystems will be turned into objects in later steps of the analysis process. Shar i ng behav i or w i t h state Atom i c i t y and I nher i t ance P i l o t s t ud i es Adm n s ra t i ve sys em ....

E.W. Dijkstra, The Structure of the T.H.E. Multiprogramming System, Communications of the ACM, No. 11, pp. 341-346, 1968.

....through global shared variables program variables that can be read and written by all processes. Initially, the shared variables were accessed by the ordinary program operations of expression evaluation and assignment; later variations included synchronization primitives such as semaphores [Dij68] and monitors [Hoa74] to control access to shared variables. Global shared variable models provide a natural representation of multiprocessing on a single computer with one or more processors connected to a central shared memory. The most natural and e#cient way to implement global shared ....

E. W. Dijkstra. The structure of the "the" multiprogramming system. Communications of the ACM, 11(5):341--346, May 1968.

....subject to failure. Ensuring the correctness of computer systems is thus an important task. It has long been acknowledged that testing is inadequate for the task of 2 ensuring the correctness of computer systems, since non exhaustive testing is insufficient, and exhaustive testing is impractical[21]. In recent years, there has been increasing attention paid to alternatives to testing, in particular software engineering and program verification. Software engineering attempts to increase the reliability of software systems by developing programming methodologies that are more likely to result ....

....is an attempt to mathematically describe the behavior of a system, and use mathematical techniques to show that the system behaves properly. Since one of the sources of the complexity of system behavior is the tremendous variability in the exact times that events occur in the operation of a system [21], most early attempts at program verification ( 22] 36] abstract away these exact times. Although these techniques, and others that followed, are important where absolute timing is not important, they are not adequate for all cases. It does not serve the passengers on a jumbo jet if the ....

Edsger W. Dijkstra. The structure of the "THE"-multiprogramming system. Communications of the ACM, 11(5):341--346, May 1968.

....both at the system and the application level. b 5 Related Work In this section I will discuss my proposal in the light of related work in the literature. 5. 1 Modularity and Protection Modularization as a technique to decompose and structure operating systems has been known for a long time [15, 5, 9]. Protection provides for isolation so that a failure or malice in one component of a system cannot adversely affect the operation and integrity of another component [12] Such failure isolation is desirable whenever two components of a system enjoy different levels of trust, such as between two ....

E. W. Dijkstra. The structure of "THE"-multiprogramming system. Communications of the ACM, 11(5):341--346, May 1968.

....bounded waiting in the Spring multiprocessor system. Section 10 concludes the paper. 2. Background on Multiprocessor Synchronization In this paper, we consider issues of mutual exclusion and synchronization on shared memory multiprocessors. Since the notion of semaphores introduced by Dijkstra [3] suffices to provide the underlying support for both mutual exclusion and synchronization, we will focus on semaphores with bounded waiting applicable to real time systems. Throughout this paper, binary semaphores are used to illustrate access to a critical section. The P( operation acquires the ....

E. W. Dijkstra. The Structure of the "THE"-Multiprogramming System. Communications of the ACM, 11(5), May 1968.

....for the construction of real time semaphores[3] semaphores which efficiently support bounded access. A software solution which improves the bounded waiting solution given in [1] as well as a hardware solution have been developed. The real time semaphore is based on the P( and V( operations [2], using an extended test and set like operation, test and set or branch. The construction of real time semaphores is 5 max guarantee ave guarantee max overhead ave overhead 0 1 2 3 4 5 6 7 8 9 10 11 12 13 0 10 20 30 40 50 60 ....

E. W. Dijkstra. The Structure of the "THE"-Multiprogramming System. Communications of the ACM, 11(5), May 1968.

....there is no special support for history proceed criteria. If such criteria are needed they must manually be encoded into attributes. Semaphore, Mutex, Lock The second basic concept of organizing concurrent access to shared data is the semaphore, which again can be tracked back to Dijkstra [87, 88]. A semaphore is a non negative integer variable with two atomic operations. One operation, commonly called P or wait , blocks until the variable is greater than zero in which case the variable is decreased atomically. The other operation, usually called V or signal, increases the variable ....

E. W. Dijkstra. The structure of the `THE' multiprogramming system. Communications of the ACM, 11(5):341--346, May 1968.

....the database and programming language communities have taken different approaches to concurrency control. In programming languages, concurrency control is based upon the concept of the co ordination of a set of cooperating processes by synchronisation. Language constructs such as semaphores [96], monitors [97] mutual exclusion [98] path expressions [99] and message passing [100] have been provided to support this concept. By contrast, in databases, concurrency is viewed as a system efficiency activity which allows parallel execution and parallel access to the data. However, each ....

Dijkstra EW. The Structure of the T.H.E. Multiprogramming System. Communications of the ACM 1968; 11,5:341-346

....language serves as a convenient environment in which to do concurrent programming [27, 3] The simulated processes can be thought of as executing in parallel, sharing a common address space. CSIM directly provides events that are similar to semaphores, and can be used for process synchronization [14, 15]. Some cooperating processes need to pass data back and forth as well as synchronize. For them, we implemented message passing queues on top of the primitives provided by CSIM. The model of the caching ring contains a process for each client processor, each CRI, and the server. These processes ....

Edsger W. Dijkstra. The Structure of the `THE' Multiprogramming System. Communications of the ACM 11(5):341-346, May, 1968.

....passed from the functions of one partition to the (external) functions of another partition. Implicit interaction on common data may only occur among functions within a partition [Liskov, 1972a, p. 195] This notion of partitions was based on Dijkstra s ideas about levels of abstraction [Dijkstra, 1968b] and my own work on the Venus operating system [Liskov, 1972b] Venus was organized as a collection of partitions, each with externally accessible functions and hidden state information, which communicated by calling one another s functions. The papers on programming methodology were concerned ....

Dijkstra, Edsger W., The Structure of the "THE"-multiprogramming System, Communications of the ACM, 11:5, May 1968, 341-346.

....1 Introduction Many modern software systems consist of collections of cooperating tasks. In such systems, mechanisms for arranging exclusive access to resources, and for synchronizing and communicating among tasks, are needed. Many such mechanisms have been proposed, including semaphores [Dijkstra 1968] , path expressions [Campbell and Habermann 1974] and various forms of message passing [Cheriton 1982; Gentleman 1985; Cheriton 1988] One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for systems with shared memory, is the monitor. ....

DIJKSTRA, E. W. 1968. The structure of the "THE"--multiprogramming system. Commun. ACM 11, 5 (May), 341--346.

No context found.

DIJKSTRA, E. W. The structure of the "THE"-multiprogramming system. Commun. ACM 11, 5 (1968), 341--346.

No context found.

DIJKSTRA, E. W. The structure of the "THE" multiprogramming system . Communications of the ACM, 11(5):341--346.

No context found.

Edsger W. Dijkstra. The structure of the "THE"-multiprogramming system. Comm. ACM, 11(5):341--346, 1968.

No context found.

E.W. Dijkstra. The Structure of the "THE" - Multiprogramming System. Communications of the ACM, 11(5):453--457, 1968.

No context found.

E. W. Dijkstra. The Structure of the "THE" Multiprogramming System. Communications of the A. C. M., 11(5):341-346, 1968.

No context found.

Dijkstra, E. W. The structure of "THE"-multiprogramming system. Comm. ACM 11, 5 (May 1968), 341346.

No context found.

Berlin. Dijkstra, E. W. 1968. The structure of the "THE"-multiprogramming system.

No context found.

E.W. Dijkstra. The Structure of the "THE"-Multiprogramming System. CACM 11(5):341-346, May, 1968.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC