Baron, R. V., et at. MACH kernel interface manual. Department of Computer Science, Carnegie-MelIon University, Pittsburgh, PA, Jan. 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....decisions in a user transparent load balancing scheme: deciding the times to initiate job migrations, determining the jobs to be migrated, and finding the places to send the migrated jobs. Previous studies have provided various answers to these questions. In ECN [8] LOCUS [26] MACH [1], and V [4] a migration decision is made upon the arrival of a new job, and the location to migrate the job is determined by polling other processors. In a second approach [ 3 ] a job is transferred to a neighboring processor whenever it is possible, and is rippled to a proper site later. In the ....

Baron, R. V., et at. MACH kernel interface manual. Department of Computer Science, Carnegie-MelIon University, Pittsburgh, PA, Jan. 1987.

..... lightweight activities, communications. In the recent years, a new organization has emerged for operating systems, in which a communication, whereas more elaborate services are implemented as specialized servers. Two representatives of this new organization are Chorus [3] 4] and Mach [5] [6] . We kernels would improve over the Unix prototype both in performance and in functionality. In addition, we hope to improve the modularity of the system, and to be able to experiment with different kind of architectures. In this way, a version of Guide has yet been implemented both on top of ....

....a set of transparently distributed object spaces in which concurrent activities may be executed; objects may be shared beween applications, and between activities within an application; objects are potentially persistent and are mapped from a secondary storage system. 3 The Chorus [4] and Mach [6] kernels supply several similar abstractions wich appear to experience with the implementation of Guide on top of Chorus and Mach, we briefly recall the basic concepts of these two systems. Section 3.1 presents the concepts common to both systems and section 3.2 describes their main differences. ....

R. Baron, D. Black, W. Bolosky, J. Chew, R. Draves, D. Golub, R. Rachid, A. Tevanian and M. Young, Mach Kernel Interface Manual, School of Computer Science, Carnegie Mellon University, sep. 1988.

....and an export license should be available by September 1988. Development and improvement are still in proces and new versions will be available to all users. Contact: Richard F. Rashid, Computer Science Department, Carnegie Mellon University, Pittsburgh, PA 15213. References: 218] 219] [220], 221] 222] 223] 224] 225] 6] 226] 227] 228] 229] 230] 231] 232] 2.33 Medusa Main Goal Medusa is a distributed operating system designed for the Cm multimicroprocessor. It is an attempt to produce a system that is modular, robust, location transparent, and to take ....

R.V. Baron, D. Black W. Bolosky, J. Chew, D.B. Golub, R.F. Rashid, A. Tevanian, and M.W. Young, "Mach Kernel Interface Manual", Technical Report, Dep. of Computer Science, Carnegie Mellon Univ., Pittsburgh, PA 15213, October 1987.

....data servers. Finally, section 5 presents the lessons drawn from this work and gives some conclusions and perspectives on fault tolerance aspects in Guide. 2 Architecture of the Guide Mach Prototype This section briefly describes the first implementation of the Guide prototype on top of Mach 2. 5 [2]. Two main components of the implementation may be distinguished: distributed execution mechanisms (jobs and activities) management of Guide objects, which includes both virtual memory management and persistent storage management. 2.1 Distributed Execution Management The Guide computational ....

R. Baron, D. Black, W. Bolosky, J. Chew, R. Draves, D. Golub, R. Rachid, A. Tevanian and M. Young., Mach Kernel Interface Manual, School of Computer Sciences, Carnegie Mellon University, September 1988.

....has emerged for operating systems, in which a micro kernel provides the basic functions of memory management, process scheduling and communication, whereas more elaborate services are implemented as specialized servers. Two representatives of this new organization are Chorus [3] 4] and Mach [5] [6] . We expect that implementing the Guide object oriented architecture on top of one of these kernels would improve over the Unix prototype both in performance and in functionality. In addition, we hope to improve the modularity of the system, and to be able to experiment with different kind of ....

....spaces in which concurrent activities may be executed; objects may be shared beween applications, and between activities within an application; objects are potentially persistent and are mapped from a secondary storage system. 3 Survey of micro kernel fonctionality The Chorus [4] and Mach [6] kernels supply several similar abstractions wich appear to provide adequate support for an object oriented model like Guide. Before describing our experience with the implementation of Guide on top of Chorus and Mach, we briefly recall the basic concepts of these two systems. Section 3.1 ....

R. Baron, D. Black, W. Bolosky, J. Chew, R. Draves, D. Golub, R. Rachid, A. Tevanian and M. Young, Mach Kernel Interface Manual, School of Computer Science, Carnegie Mellon University, sep. 1988.

....as being part of the seed but as a kernel service running at a higher layer. This is discussed below in Section 7.1.4. Conceptually, the seed layer has many similarities with microkernels that have been discussed in the operating system literature, such as Chorus [Rozier et al. 88] or Mach [Baron et al. 88] 7.1.2.1 Virtualization of the processor resource Since dedicating a physical processor to each process is not realistic in a classical multiprocessor architecture where the number of available processors is limited, our first step is to virtualize this resource. A virtual processor is ....

BARON,R.,BLACK,D.,BOLOSKY,W.,CHEW,J.,GOLUB,D.,RASHID,R.,TEVANIAN,A., AND YOUNG,M. MACH Kernel Interface Manual, Department of Computer Science, Carnegie Mellon University, September 1988.

.... of the Mach kernel, the developers of the Agora run time support system had to implement a rather sophisticated message based protocol to handle replication of shared data structures across machine boundaries [6,7] Furthermore, since Mach provides only limited support for data type tagging [5], the Agora run time layer implements a much more complete set of type retention and data translation mechanisms. We feel that the ARCADE kernel, with its built in support for replicated data units among heterogeneous machines, provides an excellent implementation environment for systems like ....

Baron, R., Black, D., Bolosky, W., Chew, J., Golub, D., Rashid, R., Tevanian, A. and Young, M., Mach Kernel Interface Manual, Department of Computer Science, Carnegie-Mellon University, December, 1987.

....two operating systems. We have collected some of the beliefs in Table 1 1, and will use them as a basis of our comparison of memory system performance in two implementations of the UNIX operating system: Ultrix from Digital Equipment Corporation [79] and Mach 3. 0 from Carnegie Mellon University [1, 10]. The beliefs in Table 1 1 are stated as assertions along with their impact for system designers. These assertions are derived from the computer systems literature and are based on past experiences [31] measurements of microbenchmarks [15, 63] and extensive measurements of real systems [3, 4, 6, ....

Robert V. Baron, David Black, William Bolosky, Jonathan Chew, Richard P. Draves, David B. Golub, Richard F. Rashid, Avadis Tevanian, Jr., and Michael Wayne Young. Mach Kernel Interface Manual. Draft, Department of Computer Science, Carnegie Mellon Univeristy.

....which a prototype implementation could be constructed in a straightforward manner. The kernel level services of Mach were designed using a different philosophy. The Mach kernel provides a much larger set of services that can be used to control low level details of task operation and interaction [3]. Another distinguishing feature of the ARCADE project is its goal of transforming a collection of interconnected (and perhaps heterogeneous) machines into a seamless computing facility. In this scenario, tasks interact with each other using uniform semantics, regardless of the configuration of ....

....part of the task structure. Data units will be fully described later. Various mechanisms are provided by ARCADE to allow a task to request that particular data units be mapped into its address space. One of these mechanisms involves the task input queue. An input queue is similar to a Mach port [3], but is not defined as a separate abstraction as in Mach. Rather, one input queue is associated with each ARCADE task. The input queue is a first in first out collection of notification packet data units, or NPDUs. When one task transfers a data unit to another task, the environment creates an ....

[Article contains additional citation context not shown here]

Baron, R., Black, D., Bolosky, W., Chew, J., Golub, D., Rashid, R., Tevanian, A. and Young, M. "MACH Kernel Interface Manual", Department of Computer Science, Carnegie-Mellon University, Pittsburgh, PA, December, 1987.

....that function. Moreover, the reconfiguration module dynamically configures the system to handle hardware and software faults. For example, if the physical environment changes (e.g. addition or removal of clusters) StarOS can be expanded or reduced to accommodate such changes. 4. 3 Mach Mach [3, 191, 242, 243, 95, 192, 15] is a multiprocessor operating system kernel developed at Carnegie Mellon University first for distributed systems, then for tightly coupled UMA multiprocessors. Later extensions of Mach also address NUMA and NORMA machines [255] Mach runs on a wide variety of uniprocessor and multiprocessor ....

R. Baron, D. Black, W. Bolosky, J. Chew, R. Draves, D. Golub, R. Rashid, A. Tevanian, and M. Young. Mach Kernel Interface Manual. School of Computer Science, Carnegie Mellon University, August 1990.

....recoverable, no application code must be changed at worst, the application may have to be recompiled or relinked. Second, the fault tolerant system must produce the same output 1 , even when failures occur, as the original non recoverable system. We have built a layer on top of Mach [3, 21] that makes multi task Mach applications transparently recoverable from fail stop processor failures. The layer implements Optimistic Recovery (OR) 18] an optimistic mechanism for fault tolerance. A transparent recovery mechanism for Mach applications is desirable for several reasons. First, ....

....true multiprocessor, so ORM will initially be restricted to tasks running on a single cpu and without shared memory between tasks. There is a third source of non determinism in Mach which we had not expected, namely the ability of one task to modify the state of another task through a system call [3]. In some cases, such as the de allocation of a port by another task, the effect is only seen when the former owner of the port tries to perform an operation on the port in this case, logging of the non deterministic event can be deferred until its effects become visible for the first time. In ....

Baron, R. V., Black, D., Bolosky, W., Chew, J., Draves, R. P., Golub, D. B., Rashid, R. F., Avadis Tevanian, J., and Young, M. W. Mach kernel interface manual. Tech. rep., CS Department, CMU, April 1990.

....for historical reasons, the two systems often use different names to describe the same thing. The remainder of this section describes the abstractions of Mach 3.0 and CHORUS relevant for understanding the rest of the paper using either the common name or both when necessary. A Task [4] or Actor [8] is an execution environment and the basic unit of resource allocation. Both include virtual memory and threads. The Mach task also includes port rights. An actor includes ports as communication resources. A task or actor can either be in kernel or user space. Threads are the basic ....

Baron, R.V. et al. MACH Kernel Interface Manual. Technical Report, School of Computer Science, Carnegie Mellon University, September, 1988.

....Hewlett Packard Laboratories. The attachment feature was implemented by Richard Sanzi at Carnegie Mellon University. The authors would like to thank Hewlett Packard for supporting this work. Further detail on the Mach system and the various kernel calls used by our debugger can be found in [1] and [3]. ....

Baron, R. V., D. L. Black, W. Bolosky, J. Chew, D. B. Golub, R. F. Rashid, A. Tevanian, Jr. and M. W. Young. MACH Kernel Interface Manual, Dept. of Computer Science, Carnegie-Mellon Univ., 15 Feb. 1988.

No context found.

R. V. Baron et al, "MACH Kernel Interface Manual," Technical Report, Dept. of Computer Science, Carnegie Mellon University, Feb 1988. 17

No context found.

Robert V. Baron, David Black, William Bolosky, Jonathan Chew, Richard P. Draves, David B. Golub, Richard F. Rashid, Avadis Tevanian, and Michael Wayne Young. Mach Kernel Interface Manual. August 1990.

No context found.

Robert V. Baron, David Black, William Bolosky, Jonathan Chew, Richard P. Draves, David B. Golub, Richard F. Rashid, Avadis Tevanian, Jr., and Michael Wayne Young. "Mach Kernel Interface Manual" Technical Report, Department of Computer Science, Carnegie-Mellon University, June 1989.

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