DOCSLIB.ORG

A Survey of Multiprocessor Operating System Kernels (DRAFT)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Survey of Multiprocessor Operating System Kernels (DRAFT) A Survey of Multiprocessor Operating System Kernels (DRAFT) Bodhisattwa Mukherjee ([email protected]) Karsten Schwan ([email protected]) Prabha Gopinath (gopinath [email protected]) GIT±CC±92/05 5 November 1993 Abstract Multiprocessors have been accepted as vehicles for improved computing speeds, cost/performance, and enhanced reliability or availability. However, the added performance requirements of user programs and functional capabilities of parallel hardware introduce new challenges to operating system design and implementa- tion. This paper reviews research and commercial developments in multiprocessor op- erating system kernels from the late 1970's to the early 1990's. The paper ®rst discusses some common operating system structuring techniques and examines the advantages and disadvantages of using each technique. It then identi®es some of the major design goals and key issues in multiprocessor operating systems. Is- sues and solution approaches are illustrated by review of a variety of research or commercial multiprocessor operating system kernels. College of Computing Georgia Institute of Technology Atlanta, Georgia 30332±0280 Contents 1 Introduction 1 2 Structuring an Operating System 4 2.1 Monolithic Systems ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 4 2.2 Capability Based Systems ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 4 2.3 Message Passing Systems ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 6 2.4 Language Based Mechanisms £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 7 2.5 Object-Oriented and Object-Supporting Operating Systems ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 8 2.6 Vertical and Horizontal Organizations ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 9 2.7 Micro-kernel Based Operating Systems £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 10 2.8 Application-speci®c Operating Systems £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 11 3 Design Issues 12 3.1 Processor Management and Scheduling ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 12 3.1.1 Heavyweight Processes to Lightweight Threads ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 12 3.1.2 Scheduler Structures ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 14 3.1.3 Scheduling Policies ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 14 3.2 Memory Management ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 19 3.2.1 Shared Virtual Memory ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 19 3.2.2 NUMA and NORMA Memory Management ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 20 3.3 Synchronization ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 23 3.3.1 Locks £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 24 3.3.2 Other Synchronization Constructs £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 26 3.4 Interprocess Communication £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 26 3.4.1 Basic Communication Primitives ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 26 3.4.2 Remote Procedure Calls ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 27 3.4.3 Object Invocations on Shared and Distributed Memory Machines ¢ ¡ ¡ £ ¤ 28 4 Sample Multiprocessor Operating System Kernels 28 4.1 HYDRA ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 28 4.1.1 Execution Environment and Processes ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 29 4.1.2 Objects and Protection ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 30 4.1.3 HYDRA and Parallel Computing ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 30 4.2 StarOS ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 30 4.2.1 Task Forces ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 32 4.2.2 Synchronization and Communication ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 33 4.2.3 Scheduling ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 33 4.2.4 Recon®guration ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 34 4.3 Mach ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¢ ¡ ¡ ¡ ¢ 34 i 4.3.1 Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 35 4.3.2 Interprocess Communication ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 36 4.3.3 Scheduling ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 36 4.3.4 The Mach 3.0 Micro-kernel £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 37 4.4 Elmwood £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 38 4.4.1 Objects and LONS ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 38 4.4.2 Processes and Synchronization ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 39 4.4.3 Interprocess Communication ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 39 4.5 Psyche £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 39 4.5.1 Synchronization £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 40 4.5.2 Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 41 4.5.3 Scheduling ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 41 4.6 PRESTO £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 41 4.6.1 Customization ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 42 4.7 KTK ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 42 4.8 Choices £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 45 4.8.1 Tasks and Threads ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 45 4.8.2 Interprocess Communication ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 45 4.8.3 Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 46 4.8.4 Persistent Objects ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 46 4.8.5 Exception Handling ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 46 4.9 Renaissance ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 46 4.9.1 Process Management ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 47 4.9.2 Synchronization £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 47 4.10DYNIX ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 47 4.10.1Process Management and Scheduling ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 47 4.10.2Synchronization £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 48 4.10.3Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 48 4.11UMAX ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ 48 4.11.1Process Management and Scheduling ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 48 4.11.2Synchronization £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 48 4.11.3Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 48 4.12Chrysalis ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 48 4.12.1Process Management and Scheduling ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 49 4.12.2Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 49 4.12.3Synchronization £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 49 4.13RP3 ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ 49 4.13.1Process Management and Scheduling ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ 50 4.13.2Memory Management ¡ ¡ ¡ ¢ ¡ £ ¤ £ ¡ ¡ ¢ ¡ ¡ ¢ ¡ ¡ £ ¤ £ ¡ ¢ ¡ ¡ ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ 50 4.14Operating Systems for Distributed Memory Machines ¡ ¢ ¡ ¡ ¢ ¡ £ ¡ ¢ ¡ ¡ ¢ ¡ ¡ ¡ ¢ 50 ii 5 Conclusions and Future Work 52 iii 1 Introduction Parallel processing has become the premier approach for increasing the computational power of modern supercomputers, in part driven by large-scale scienti®c and engineering appli- cations like weather prediction, materials and process modeling, and others, all of which require GigaFlop computing speeds and Terabytes of rapidly accessible primary and sec- ondary storage. However, perhaps more important than the HPCC applications named above are commercial motivations for the development of parallel machines, which include improved machine cost/performance, scalability to different application requirements, and enhanced reliability or availability. The purpose of this survey is to review some of the major concepts in operating systems for parallel machines, roughly re¯ecting the state of the art in the early 1990's. More impor- tantly, we identify the main research issues to be addressed by any operating system for a multiprocessor machine, and we review the resulting solution approaches taken by a variety of commercial and research systems constructed during the last decade. Moreover, it should be apparent to the reader upon ®nishing this paper that many of these solution approaches are and have been applied to both parallel and distributed target hardware. This `convergence' of technologies originally developed for parallel vs. distributed systems, by partially divergent technical communities and sometimes discussed with
Load more

Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗
    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
    [Show full text]
  • Operating Systems and Virtualisation Security Knowledge Area (Draft for Comment)
    OPERATING SYSTEMS AND VIRTUALISATION SECURITY KNOWLEDGE AREA (DRAFT FOR COMMENT) AUTHOR: Herbert Bos – Vrije Universiteit Amsterdam EDITOR: Andrew Martin – Oxford University REVIEWERS: Chris Dalton – Hewlett Packard David Lie – University of Toronto Gernot Heiser – University of New South Wales Mathias Payer – École Polytechnique Fédérale de Lausanne © Crown Copyright, The National Cyber Security Centre 2019. Following wide community consultation with both academia and industry, 19 Knowledge Areas (KAs) have been identified to form the scope of the CyBOK (see diagram below). The Scope document provides an overview of these top-level KAs and the sub-topics that should be covered under each and can be found on the project website: https://www.cybok.org/. We are seeking comments within the scope of the individual KA; readers should note that important related subjects such as risk or human factors have their own knowledge areas. It should be noted that a fully-collated CyBOK document which includes issue 1.0 of all 19 Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas. Operating Systems and Virtualisation Security Herbert Bos Vrije Universiteit Amsterdam April 2019 INTRODUCTION In this knowledge area, we introduce the principles, primitives and practices for ensuring security at the operating system and hypervisor levels. We shall see that the challenges related to operating system security have evolved over the past few decades, even if the principles have stayed mostly the same. For instance, when few people had their own computers and most computing was done on multiuser (often mainframe-based) computer systems with limited connectivity, security was mostly focused on isolating users or classes of users from each other1.
    [Show full text]
  • TOWARD a POETICS of NEW MEDIA By
    'A Kind of Thing That Might Be': Toward A Poetics of New Media Item Type text; Electronic Dissertation Authors Thompson, Jason Craig Publisher The University of Arizona. Rights Copyright © is held by the author. Digital access to this material is made possible by the University Libraries, University of Arizona. Further transmission, reproduction or presentation (such as public display or performance) of protected items is prohibited except with permission of the author. Download date 28/09/2021 20:28:02 Link to Item http://hdl.handle.net/10150/194959 ‘A KIND OF THING THAT MIGHT BE’: TOWARD A POETICS OF NEW MEDIA by Jason Thompson _____________________ Copyright © Jason Thompson 2008 A Dissertation Submitted to the Faculty of the DEPARTMENT OF ENGLISH In Partial Fulfillment of the Requirements For the Degree of DOCTOR OF PHILOSOPHY WITH A MAJOR IN RHETORIC, COMPOSITION, AND THE TEACHING OF ENGLISH In the Graduate College THE UNIVERSITY OF ARIZONA 2008 2 THE UNIVERSITY OF ARIZONA GRADUATE COLLEGE As members of the Dissertation Committee, we certify that we have read the dissertation prepared by Jason Thompson entitled A Kind of Thing that Might Be: Toward a Rhetoric of New Media and recommend that it be accepted as fulfilling the dissertation requirement for the Degree of Doctor of Philosophy. ______________________________________________________________________ Date: 07/07/2008 Ken McAllister _______________________________________________________________________ Date: 07/07/2008 Theresa Enos _______________________________________________________________________ Date: 07/07/2008 John Warnock Final approval and acceptance of this dissertation is contingent upon the candidate’s submission of the final copies of the dissertation to the Graduate College. I hereby certify that I have read this dissertation prepared under my direction and recommend that it be accepted as fulfilling the dissertation requirement.
    [Show full text]
  • The Design of the EMPS Multiprocessor Executive for Distributed Computing
    The design of the EMPS multiprocessor executive for distributed computing Citation for published version (APA): van Dijk, G. J. W. (1993). The design of the EMPS multiprocessor executive for distributed computing. Technische Universiteit Eindhoven. https://doi.org/10.6100/IR393185 DOI: 10.6100/IR393185 Document status and date: Published: 01/01/1993 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.
    [Show full text]
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-876 Technical Report ISSN 1476-2986 Number 876 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son September 2015 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2015 Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, SRI International Approved for public release; distribution is unlimited. Sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and FA8750-11-C-0249 (“MRC2”) as part of the DARPA CRASH and DARPA MRC research programs. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. Additional support was received from St John’s College Cambridge, the SOAAP Google Focused Research Award, the RCUK’s Horizon Digital Economy Research Hub Grant (EP/G065802/1), the EPSRC REMS Programme Grant (EP/K008528/1), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), and Thales E-Security. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract This technical report describes CHERI ISAv4, the fourth version of the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA)1 being developed by SRI International and the University of Cambridge.
    [Show full text]
  • Blackberry QNX Multimedia Suite
    PRODUCT BRIEF QNX Multimedia Suite The QNX Multimedia Suite is a comprehensive collection of media technology that has evolved over the years to keep pace with the latest media requirements of current-day embedded systems. Proven in tens of millions of automotive infotainment head units, the suite enables media-rich, high-quality playback, encoding and streaming of audio and video content. The multimedia suite comprises a modular, highly-scalable architecture that enables building high value, customized solutions that range from simple media players to networked systems in the car. The suite is optimized to leverage system-on-chip (SoC) video acceleration, in addition to supporting OpenMAX AL, an industry open standard API for application-level access to a device’s audio, video and imaging capabilities. Overview Consumer’s demand for multimedia has fueled an anywhere- o QNX SDK for Smartphone Connectivity (with support for Apple anytime paradigm, making multimedia ubiquitous in embedded CarPlay and Android Auto) systems. More and more embedded applications have require- o Qt distributions for QNX SDP 7 ments for audio, video and communication processing capabilities. For example, an infotainment system’s media player enables o QNX CAR Platform for Infotainment playback of content, stored either on-board or accessed from an • Support for a variety of external media stores external drive, mobile device or streamed over IP via a browser. Increasingly, these systems also have streaming requirements for Features at a Glance distributing content across a network, for instance from a head Multimedia Playback unit to the digital instrument cluster or rear seat entertainment units. Multimedia is also becoming pervasive in other markets, • Software-based audio CODECs such as medical, industrial, and whitegoods where user interfaces • Hardware accelerated video CODECs are increasingly providing users with a rich media experience.
    [Show full text]
  • Blackberry Playbook OS 2.0 Performs. Best in Class Communications
    BlackBerry PlayBook OS 2.0 Performs. Best in class communications. Powerful productivity. Performance powerhouse. What’s new and exciting about PlayBook™ OS 2.0 A proven performance powerhouse PlayBook OS 2.0 builds on proven performance through powerful hardware and intuitive, easy to use gestures. BlackBerry® PlayBook™ packs a blazing fast dual core processor, two HD 1080p video cameras, and 1 GB of RAM for a high performance experience that is up to the task – whatever it may be. The best of BlackBerry® comes built-in The BlackBerry PlayBook now gives you the BlackBerry communications experience you love, built for a tablet. PlayBook OS 2.0 introduces built-in email that lets you create, edit and format messages, and built-in contacts app and social calendar that connect to your social networks to give you a complete profile ™ of your contacts, including recent status updates. So, seize the BlackBerry App World moment and share it with the power of BlackBerry. The BlackBerry PlayBook has all your favorite apps and thousands more. Games like Angry Birds and Cut The Rope, BlackBerry® Bridge™ Technology social networking sites like Facebook, and even your favorite books from Kobo - the apps you want are here for you to New BlackBerry® Bridge™ features let your BlackBerry® smartphone discover in the BlackBerry AppWorld™ storefront. act as a keyboard and mouse for your BlackBerry PlayBook, giving you wireless remote control of your tablet. Perfect for pausing a movie when your BlackBerry PlayBook is connected to your TV with An outstanding web experience an HDMI connection. Plus, if you’re editing a document or browsing BlackBerry PlayBook puts the power of the real Internet at your a webpage on your BlackBerry smartphone and want to see it on a fingertips with a blazing fast Webkit engine supporting HTML5 larger display, BlackBerry Bridge lets you switch screens to view on and Adobe® Flash® 11.1.
    [Show full text]
  • QNX Neutrino® Realtime Operating System
    PRODUCT BRIEF QNX Neutrino® Realtime Operating System QNX Neutrino® is a full-featured and robust operating system designed to enable the next-generation of products for automotive, medical and industrial embedded systems. Microkernel design and modular architecture enable customers to create highly optimized and reliable systems with low total cost of ownership. With QNX Neutrino®, embedded systems designers can create compelling, safe and secure devices built on a highly reliable operating system software foundation that helps guard against system malfunctions, malware and cyber security breaches. For over 35 years, thousands of companies have deployed and The QNX Neutrino microkernel memory-protected architecture trusted QNX realtime technology to ensure the best combination provides a foundation to build safety-critical systems. QNX of performance, security and reliability in the world’s most Neutrino® is 100% API compatible with QNX pre-certified mission-critical systems. software products that address compliance with safety certifica- tions in automotive (ISO 26262), industrial safety (IEC 61508) and Built-in mission critical reliability medical devices (IEC 62304). Time-tested and field-proven, the QNX Neutrino® is built on a true microkernel architecture. Under this system, every driver, Maximize software investments application, protocol stack, and filesystem runs outside the kernel QNX Neutrino® provides a common software platform that can be in the safety of memory-protected user space. Virtually any deployed for safety certified and non-certified projects across a component can fail and be automatically restarted without broad range of hardware platforms. Organizations can reduce aecting other components or the kernel. No other commercial duplication, costs and risks associated with the deployment of RTOS provides such a high level of fault containment and recovery.
    [Show full text]
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • P U B L I C a T I E S
    P U B L I C A T I E S 1 JANUARI – 31 DECEMBER 2001 2 3 INHOUDSOPGAVE Centrale diensten..............................................................................................................5 Coördinatoren...................................................................................................................8 Faculteit Letteren en Wijsbegeerte..................................................................................9 - Emeriti.........................................................................................................................9 - Vakgroepen...............................................................................................................10 Faculteit Rechtsgeleerdheid...........................................................................................87 - Vakgroepen...............................................................................................................87 Faculteit Wetenschappen.............................................................................................151 - Vakgroepen.............................................................................................................151 Faculteit Geneeskunde en Gezondheidswetenschappen............................................268 - Vakgroepen.............................................................................................................268 Faculteit Toegepaste Wetenschappen.........................................................................398 - Vakgroepen.............................................................................................................398
    [Show full text]