DOCSLIB.ORG

Operating System Support for Parallel Processes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Operating System Support for Parallel Processes Operating System Support for Parallel Processes Barret Rhoden Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2014-223 http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-223.html December 18, 2014 Copyright © 2014, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Operating System Support for Parallel Processes by Barret Joseph Rhoden A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Eric Brewer, Chair Professor Krste Asanovi´c Professor David Culler Professor John Chuang Fall 2014 Operating System Support for Parallel Processes Copyright 2014 by Barret Joseph Rhoden 1 Abstract Operating System Support for Parallel Processes by Barret Joseph Rhoden Doctor of Philosophy in Computer Science University of California, Berkeley Professor Eric Brewer, Chair High-performance, parallel programs want uninterrupted access to physical resources. This characterization is true not only for traditional scientific computing, but also for high- priority data center applications that run on parallel processors. These applications require high, predictable performance and low latency, and they are important enough to warrant engineering effort at all levels of the software stack. Given the recent resurgence of interest in parallel computing as well as the increasing importance of data center applications, what changes can we make to operating system abstractions to support parallel programs? Akaros is a research operating system designed for single-node, large-scale SMP and many-core architectures. The primary feature of Akaros is a new process abstraction called the \Many-Core Process" (MCP) that embodies transparency, application control of physical resources, and performance isolation. The MCP is built on the idea of separating cores from threads: the operating system grants spatially partitioned cores to the MCP, and the application schedules its threads on those cores. Data centers typically have a mix of high- priority applications and background batch jobs, where the demands of the high-priority application can change over time. For this reason, an important part of Akaros is the provisioning, allocation, and preemption of resources, and the MCP must be able to handle having a resource revoked at any moment. In this work, I describe the MCP abstraction and the salient details of Akaros. I discuss how the kernel and user-level libraries work together to give an application control over its physical resources and to adapt to the revocation of cores at any time | even when the code is holding locks. I show an order of magnitude less interference for the MCP compared to Linux, more resilience to the loss of cores for an HPC application, and how a customized user-level scheduler can increase the performance of a simple webserver. i Contents Contents i List of Figures iii List of Tables v 1 Introduction 1 2 Background on Operating Systems 4 2.1 System Calls . 4 2.2 Threads, Concurrency, and Parallelism . 7 2.3 Scheduling and Competition . 20 2.4 Synchronization . 27 2.5 Performance Isolation . 30 3 The Basics of the Many-Core Process and Akaros 34 3.1 MCP Basics . 34 3.2 Akaros Details . 36 4 Life for a Many-Core Process 48 4.1 Procinfo and Procdata . 48 4.2 Virtual Cores . 49 4.3 MCPs from Creation to Entry . 52 4.4 User-level Scheduling . 57 4.5 Impact of Dedicated Cores . 70 5 Event Delivery 88 5.1 Concurrent Queues for Payloads . 89 5.2 The Event Delivery Subsystem . 100 5.3 Never Miss an Important Event . 108 6 Virtual Core Preemption 116 6.1 Preemption Basics . 118 ii 6.2 Preemption Detection and Recovery Locks . 123 6.3 Handling Preemption . 141 7 Applications 149 7.1 Fluidanimate . 149 7.2 Webserver . 151 8 Conclusion 160 Bibliography 162 iii List of Figures 4.1 FTQ Raw Output, c89, Linux, Core 7 . 71 4.2 FFT @ 3000 Hz, c89, Linux, Core 7 . 72 4.3 FFT @ 500 Hz, c89, Linux, Core 7 . 72 4.4 FFT @ 100 Hz, c89, Linux, Core 7 . 73 4.5 FFT @ 100 Hz, c89, Old Akaros, Core 7 . 74 4.6 FFT @ 100 Hz, c89, Akaros, Core 7 . 75 4.7 FFT @ 500 Hz, c89, Akaros, Core 7 . 75 4.8 FFT @ 3000 Hz, c89, Akaros, Core 7 . 76 4.9 FFT @ 3000 Hz, c89, Linux, Core 31 . 77 4.10 FFT @ 3000 Hz, c89, Akaros, Core 31 . 77 4.11 FFT @ 500 Hz, c89, Linux, Core 31 . 78 4.12 FFT @ 500 Hz, c89, Akaros, Core 31 . 78 4.13 FFT @ 100 Hz, c89, Linux, Core 31 . 79 4.14 FFT @ 100 Hz, c89, Akaros, Core 31 . 79 4.15 FTQ Raw Data, c89, Akaros, Core 7 . 80 4.16 FTQ Raw Data, c89, Akaros, Core 31 . 81 4.17 FFT @ 3000 Hz, hossin, Linux, Core 7 . 82 4.18 FFT @ 3000 Hz, hossin, Akaros, Core 7 . 82 4.19 FFT @ 500 Hz, hossin, Linux, Core 7 . 83 4.20 FFT @ 500 Hz, hossin, Akaros, Core 7 . 83 4.21 FFT @ 100 Hz, hossin, Linux, Core 7 . 84 4.22 FFT @ 100 Hz, hossin, Akaros, Core 7 . 84 4.23 FTQ Raw Data, hossin, Akaros, Core 7 . 85 4.24 FTQ Raw Data, hossin, Linux, Core 7 . 86 6.1 Akaros Spinlocks, 4 Threads, Acquisition Latency . 135 6.2 Linux Spinlocks, 31 Threads, Acquisition Times . 135 6.3 MCS locks, 31 Threads, Acquisition Times . 137 6.4 Akaros, Basic MCS locks, 31 Threads, Lock Throughput . 138 6.5 Akaros, MCS-PDRO locks, 31 Threads, Lock Throughput . 138 6.6 Akaros, MCS-PDRN locks, 31 Threads, Lock Throughput . 139 iv 7.1 Fluidanimate, Akaros, 64 Threads, 31 Cores . 151 7.2 Fluidanimate Performance on Akaros and Linux with Preemption . 152 7.3 Fluidanimate Relative Performance on Akaros and Linux with Preemption . 152 7.4 Akaros Kweb, Custom-2LS, Throughput vs. Workers . 156 7.5 Kweb and Fluidanimate Throughput with Preemption . 158 v List of Tables 4.1 Average Thread Context-Switch Latency (nsec) . 68 4.2 Akaros Context-Switch Latency (nsec) . 69 6.1 Spinlock Acquisition Latency (in ticks) . 134 6.2 MCS Lock Acquisition Latency (in ticks) . 136 7.1 Fluidanimate Runtime (seconds) . 150 7.2 Kweb Throughput, 100 connections of 100,000 calls each . 154 vi Acknowledgments I have been extremely fortunate over the past seven years. Not only did I have the oppor- tunity to pursue a project I found interesting, but I did so while working with excellent people. Both my research opportunity and the group environment are the product of my advisor: Eric Brewer. I would like to thank Eric for his inspiration and guidance | especially his implicit guidance as a role model. Although research is important, it is less important than a work-life balance and being \safe in your own skin." Eric gave me the breathing room necessary to work on Akaros and allowed me to \do the right thing," even if it took longer. I would also like to thank my committee, especially David Culler, for providing a much- needed historical perspective for my work. Additionally, David Wessel's music application was the original inspiration for the separation of provisioning and allocation in Akaros. The bulk of my time was spent with other graduate students and developers, and my work would not have been possible without them. Kevin Klues has been my partner in crime for a number of years now. It's hard to believe that the end of our era in Berkeley is finally here. David Zhu and I have had discussions since our first semester here together. Andrew Waterman is an impressive coder who tends to know what I am thinking before I say it. Paul Pearce developed Akaros's initial network drivers, and Andrew Gallatin vastly improved the more recent Plan 9 network stack. I would be lucky to work with any of them in the future. Ron Minnich and I met in 2009, but we did not work together until our serendipitous pairing as host and intern at Google in 2013. He was instrumental both in porting the guts of Plan 9 to Akaros and in using FTQ. Ron breathed new life into Akaros, greatly increasing its chances of having a life beyond graduate school. More importantly, Ron is the real deal | authentic and generous, and I hope to be more like him. My family has been very supportive over the years. They have always provided a home in Pittsburgh, complete with nieces and nephews, for whenever I was in town and needed to relax. Finally, I would like to thank my wife, Tamara Broderick. Not only did she help with FTQ and R, but she has been my biggest supporter. Whether it was coining the name \Akaros" or designing giraffe-themed merchandise, she has always been there for me, and I look forward to returning the favor. 1 Chapter 1 Introduction There are limitations to what we can do with computers. System designers make trade-offs, and over time certain designs should be reevaluated | especially when there is a change in the landscape of computing. One such change is the resurgence of interest in parallel computing due to the industry's failure to increase uniprocessor performance[5].
Load more

Recommended publications
  • Unix Protection
    View access control as a matrix Protection Ali Mashtizadeh Stanford University Subjects (processes/users) access objects (e.g., files) • Each cell of matrix has allowed permissions • 1 / 39 2 / 39 Specifying policy Two ways to slice the matrix Manually filling out matrix would be tedious • Use tools such as groups or role-based access control: • Along columns: • - Kernel stores list of who can access object along with object - Most systems you’ve used probably do this dir 1 - Examples: Unix file permissions, Access Control Lists (ACLs) Along rows: • dir 2 - Capability systems do this - More on these later. dir 3 3 / 39 4 / 39 Outline Example: Unix protection Each process has a User ID & one or more group IDs • System stores with each file: • 1 Unix protection - User who owns the file and group file is in - Permissions for user, any one in file group, and other Shown by output of ls -l command: 2 Unix security holes • user group other owner group - rw- rw- r-- dm cs140 ... index.html 3 Capability-based protection - Eachz}|{ groupz}|{ z}|{ of threez}|{ lettersz }| { specifies a subset of read, write, and execute permissions - User permissions apply to processes with same user ID - Else, group permissions apply to processes in same group - Else, other permissions apply 5 / 39 6 / 39 Unix continued Non-file permissions in Unix Directories have permission bits, too • Many devices show up in file system • - Need write permission on a directory to create or delete a file - E.g., /dev/tty1 permissions just like for files Special user root (UID 0) has all
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • Openvms Record Management Services Reference Manual
    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
    [Show full text]
  • System Calls System Calls
    System calls We will investigate several issues related to system calls. Read chapter 12 of the book Linux system call categories file management process management error handling note that these categories are loosely defined and much is behind included, e.g. communication. Why? 1 System calls File management system call hierarchy you may not see some topics as part of “file management”, e.g., sockets 2 System calls Process management system call hierarchy 3 System calls Error handling hierarchy 4 Error Handling Anything can fail! System calls are no exception Try to read a file that does not exist! Error number: errno every process contains a global variable errno errno is set to 0 when process is created when error occurs errno is set to a specific code associated with the error cause trying to open file that does not exist sets errno to 2 5 Error Handling error constants are defined in errno.h here are the first few of errno.h on OS X 10.6.4 #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ #define EINTR 4 /* Interrupted system call */ #define EIO 5 /* Input/output error */ #define ENXIO 6 /* Device not configured */ #define E2BIG 7 /* Argument list too long */ #define ENOEXEC 8 /* Exec format error */ #define EBADF 9 /* Bad file descriptor */ #define ECHILD 10 /* No child processes */ #define EDEADLK 11 /* Resource deadlock avoided */ 6 Error Handling common mistake for displaying errno from Linux errno man page: 7 Error Handling Description of the perror () system call.
    [Show full text]
  • Advanced Components on Top of a Microkernel
    Faculty of Computer Science Institute for System Architecture, Operating Systems Group Advanced Components on Top of A Microkernel Björn Döbel What we talked about so far • Microkernels are cool! • Fiasco.OC provides fundamental mechanisms: – Tasks (address spaces) • Container of resources – Threads • Units of execution – Inter-Process Communication • Exchange Data • Timeouts • Mapping of resources TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 2 / 54 Lecture Outline • Building a real system on top of Fiasco.OC • Reusing legacy libraries – POSIX C library • Device Drivers in user space – Accessing hardware resources – Reusing Linux device drivers • OS virtualization on top of L4Re TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 3 / 54 Reusing Existing Software • Often used term: legacy software • Why? – Convenience: • Users get their “favorite” application on the new OS – Effort: • Rewriting everything from scratch takes a lot of time • But: maintaining ported software and adaptions also does not come for free TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 4 / 54 Reusing Existing Software • How? – Porting: • Adapt existing software to use L4Re/Fiasco.OC features instead of Linux • Efficient execution, large maintenance effort – Library-level interception • Port convenience libraries to L4Re and link legacy applications without modification – POSIX C libraries, libstdc++ – OS-level interception • Wine: implement Windows OS interface on top of new OS – Hardware-level: • Virtual Machines TU Dresden, 2012-07-24 L4Re:
    [Show full text]
  • Software Product Description and Quickspecs
    VSI OpenVMS Alpha Version 8.4-2L2 Operating System DO-DVASPQ-01A Software Product Description and QuickSpecs PRODUCT NAME: VSI OpenVMS Alpha Version 8.4-2L2 DO-DVASPQ-01A This SPD and QuickSpecs describes the VSI OpenVMS Alpha Performance Release Operating System software, Version 8.4-2L2 (hereafter referred to as VSI OpenVMS Alpha V8.4-2L2). DESCRIPTION OpenVMS is a general purpose, multiuser operating system that runs in both production and development environments. VSI OpenVMS Alpha Version 8.4-2L2 is the latest release of the OpenVMS Alpha computing environment by VMS Software, Inc (VSI). VSI OpenVMS Alpha V8.4-2L2 is compiled to take advantage of architectural features such as byte and word memory reference instructions, and floating-point improvements, which are available only in HPE AlphaServer EV6 or later processors. This optimized release improves performance by taking advantage of faster hardware-based instructions that were previously emulated in software. NOTE: VSI OpenVMS Alpha V8.4-2L2 does not work on, and is not supported on, HPE AlphaServer pre-EV6 systems. OpenVMS Alpha supports HPE’s AlphaServer series computers. OpenVMS software supports industry standards, facilitating application portability and interoperability. OpenVMS provides symmetric multiprocessing (SMP) support for multiprocessing systems. The OpenVMS operating system can be tuned to perform well in a wide variety of environments. This includes combinations of compute-intensive, I/O-intensive, client/server, real-time, and other environments. Actual system performance depends on the type of computer, available physical memory, and the number and type of active disk and tape drives. The OpenVMS operating system has well-integrated networking, distributed computing, client/server, windowing, multi-processing, and authentication capabilities.
    [Show full text]
  • Lecture Notes in Assembly Language
    Lecture Notes in Assembly Language Short introduction to low-level programming Piotr Fulmański Łódź, 12 czerwca 2015 Spis treści Spis treści iii 1 Before we begin1 1.1 Simple assembler.................................... 1 1.1.1 Excercise 1 ................................... 2 1.1.2 Excercise 2 ................................... 3 1.1.3 Excercise 3 ................................... 3 1.1.4 Excercise 4 ................................... 5 1.1.5 Excercise 5 ................................... 6 1.2 Improvements, part I: addressing........................... 8 1.2.1 Excercise 6 ................................... 11 1.3 Improvements, part II: indirect addressing...................... 11 1.4 Improvements, part III: labels............................. 18 1.4.1 Excercise 7: find substring in a string .................... 19 1.4.2 Excercise 8: improved polynomial....................... 21 1.5 Improvements, part IV: flag register ......................... 23 1.6 Improvements, part V: the stack ........................... 24 1.6.1 Excercise 12................................... 26 1.7 Improvements, part VI – function stack frame.................... 29 1.8 Finall excercises..................................... 34 1.8.1 Excercise 13................................... 34 1.8.2 Excercise 14................................... 34 1.8.3 Excercise 15................................... 34 1.8.4 Excercise 16................................... 34 iii iv SPIS TREŚCI 1.8.5 Excercise 17................................... 34 2 First program 37 2.1 Compiling,
    [Show full text]
  • Android Porting Guide Step by Step
    Android Porting Guide Step By Step ChristoferBarometric remains Derron left-handstill connects: after postulationalSpenser snoops and kinkilywispier or Rustin preacquaint microwaves any caterwaul. quite menacingly Hewie graze but intubated connectedly. her visionaries hereditarily. The ramdisk of the logs should be placed in API calls with the thumb of the code would cause problems. ROMs are desperate more difficult to figure naked but the basic skills you seek be taught here not be applied in principle to those ROMs. Find what catch the prescribed procedures to retrieve taken. Notification data of a surface was one from android porting guide step by step by specific not verify your new things at runtime. Common interface to control camera device on various shipsets and used by camera source plugin. If tap have executed any state the commands below and see want i run the toolchain build again, like will need maybe open a fancy shell. In cases like writing, the input API calls are they fairly easy to replace, carpet the accelerometer input may be replaced by keystrokes, say. Sometimes replacing works and some times editing. These cookies do not except any personally identifiable information. When you decide up your email account assess your device, Android automatically uses SSL encrypted connection. No custom ROM developed for team yet. And Codeaurora with the dtsi based panel configuration, does charity have a generic drm based driver under general hood also well? Means describe a lolipop kernel anyone can port Marshmallow ROMs? Fi and these a rain boot. After flashing protocol. You least have no your fingertips the skills to build a full operating system from code and install navigate to manage running device, whenever you want.
    [Show full text]
  • Sched-ITS: an Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course
    Wright State University CORE Scholar Browse all Theses and Dissertations Theses and Dissertations 2017 Sched-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course Bharath Kumar Koya Wright State University Follow this and additional works at: https://corescholar.libraries.wright.edu/etd_all Part of the Computer Engineering Commons, and the Computer Sciences Commons Repository Citation Koya, Bharath Kumar, "Sched-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course" (2017). Browse all Theses and Dissertations. 1745. https://corescholar.libraries.wright.edu/etd_all/1745 This Thesis is brought to you for free and open access by the Theses and Dissertations at CORE Scholar. It has been accepted for inclusion in Browse all Theses and Dissertations by an authorized administrator of CORE Scholar. For more information, please contact [email protected]. SCHED – ITS: AN INTERACTIVE TUTORING SYSTEM TO TEACH CPU SCHEDULING CONCEPTS IN AN OPERATING SYSTEMS COURSE A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science By BHARATH KUMAR KOYA B.E, Andhra University, India, 2015 2017 Wright State University WRIGHT STATE UNIVERSITY GRADUATE SCHOOL April 24, 2017 I HEREBY RECOMMEND THAT THE THESIS PREPARED UNDER MY SUPERVISION BY Bharath Kumar Koya ENTITLED SCHED-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating System Course BE ACCEPTED IN PARTIAL FULFILLMENT OF THE REQIREMENTS FOR THE DEGREE OF Master of Science. _____________________________________ Adam R. Bryant, Ph.D. Thesis Director _____________________________________ Mateen M. Rizki, Ph.D. Chair, Department of Computer Science and Engineering Committee on Final Examination _____________________________________ Adam R.
    [Show full text]
  • Scheduling: Introduction
    7 Scheduling: Introduction By now low-level mechanisms of running processes (e.g., context switch- ing) should be clear; if they are not, go back a chapter or two, and read the description of how that stuff works again. However, we have yet to un- derstand the high-level policies that an OS scheduler employs. We will now do just that, presenting a series of scheduling policies (sometimes called disciplines) that various smart and hard-working people have de- veloped over the years. The origins of scheduling, in fact, predate computer systems; early approaches were taken from the field of operations management and ap- plied to computers. This reality should be no surprise: assembly lines and many other human endeavors also require scheduling, and many of the same concerns exist therein, including a laser-like desire for efficiency. And thus, our problem: THE CRUX: HOW TO DEVELOP SCHEDULING POLICY How should we develop a basic framework for thinking about scheduling policies? What are the key assumptions? What metrics are important? What basic approaches have been used in the earliest of com- puter systems? 7.1 Workload Assumptions Before getting into the range of possible policies, let us first make a number of simplifying assumptions about the processes running in the system, sometimes collectively called the workload. Determining the workload is a critical part of building policies, and the more you know about workload, the more fine-tuned your policy can be. The workload assumptions we make here are mostly unrealistic, but that is alright (for now), because we will relax them as we go, and even- tually develop what we will refer to as ..
    [Show full text]
  • Systemprogrammierung Grundlage Von Betriebssystemen
    Systemprogrammierung Grundlage von Betriebssystemen Sachwortverzeichnis c Wolfgang Schr¨oder-Preikschat 27. Januar 2017 Die in der Vorlesung (mundlich¨ oder schriftlich) verwendeten Akronyme und Sachworte sind in der nachfolgenden Aufz¨ahlung zusammengefasst. Dabei werden die Akronyme nach den Sachwor- ten, fur¨ die sie die Verkurzung¨ bilden, aufgeschlusselt.¨ Fur¨ englischsprachige Sachw¨orter werden, soweit bekannt, die deutschsprachigen Entsprechungen angegeben. In der Beschreibung durch das "-Zeichen angefuhrte¨ Sachw¨orter zeigen einen Kreuzverweis an. Jedes Sachwort wird erkl¨art, wo- bei dies im Zusammenhang mit dem hier relevanten Kontext der "Systemprogrammierung und in Bezug auf Betriebssysteme geschieht. Die Formulierungen erheben nicht den Anspruch auf Gultigkeit¨ auch fur¨ andere Fachrichtungen in der Informatik. Ebenso erhebt die Aufz¨ahlung nicht den Anspruch auf Vollst¨andigkeit fur¨ das in der Vorlesung behandelte Fachgebiet. Der vorliegende Text ist ein Nachschlagewerk, dessen Lekture,¨ im Gegensatz zu einem Lehr- buch mit durchgehendem roten Faden, fur¨ gew¨ohnlich nicht von vorne nach hinten empfohlen ist. Vielmehr ist der Text Begleitmaterial zu den Vorlesungsfolien. Neben Systemprogrammierung sind hier insbesondere die Lehrveranstaltungen Betriebssysteme, Betriebssystemtechnik, Nebenl¨aufige Systeme und Echtzeitsysteme eingeschlossen. Daruber¨ hinaus kommen aber auch Lehrveranstal- tungen zu den Themen Rechnerorganisation und Rechnerarchitektur als Bezugspunkt in Frage. Viele der dort (mundlich¨ oder schriftlich)
    [Show full text]
  • Proceedings, ITC/USA
    THE EFFICIENT USE OF A VAX COMPUTER IN THE REAL-TIME TELEMETRY ENVIRONMENT Item Type text; Proceedings Authors Robbins, Robert B. Publisher International Foundation for Telemetering Journal International Telemetering Conference Proceedings Rights Copyright © International Foundation for Telemetering Download date 01/10/2021 10:32:25 Link to Item http://hdl.handle.net/10150/613377 THE EFFICIENT USE OF A VAX COMPUTER IN THE REAL-TIME TELEMETRY ENVIRONMENT Robert B. Robbins Sangamo-Weston Incorporated Data Systems Division Post Office Box 3041 Sarasota, Florida 33578 ABSTRACT The use of a Digital Equipment Corporation VAX computer under the VMS operating system, in a real-time telemetry environment, brings with it many advantages. These advantages pertain to its ability to handle real-time telemetry processing in an efficient and relatively straight forward manner. The author will use the TELSET, TELDAX and TELFOR telemetry software systems as the basis for demonstrating the techniques which have allowed the real-time telemetry user to take advantage of a 32-bit, virtual addressing, architecture. INTRODUCTION Many real-time telemetry computer users believe in the need for 32-bit processing of telemetry data once it has entered the central processor. We at Sangamo-Weston agree with this belief and have successfully designed a real-time telemetry data acquisition system which efficiently uses the VAX computer under the VMS operating system. SYSTEM SOFTWARE The software written for this system achieves three goals. TELSET, which sets up the telemetry front-end hardware units, is written in VAX-11 MACRO. TELDAX the real- time data acquisition executive and TELFOR the telemetry data acquisition formatted storage process are written in interactive VAX-11 FORTRAN and are menu driven.
    [Show full text]