DOCSLIB.ORG

Real-Time Posix: an Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

REAL-TIME POSIX: AN OVERVIEW Michael González Harbour1 Departamento de Electrónica Universidad de Cantabria Avda. los Castros s/n 39005 - Santander SPAIN E-mail: [email protected] Abstract Table I. List of POSIX Base Standards The POSIX standard defines a portable interface for UNIX- POSIX.1 System Interface (basic reference standard)a,b based operating systems. The goal of this increasingly POSIX.2 Shell and Utilitiesa important standard is source-level portability of applications. In this paper we discuss the real-time extensions to POSIX and POSIX.3 Methods for Testing Conformance to POSIXa how these extensions address the needs of applications with real-time requirements. POSIX.4 Real-time Extensions POSIX.4a Threads Extensions I. INTRODUCTION POSIX.4b Additional Real-time Extensions POSIX is the acronym for Portable Operating System POSIX.6 Security Extensions Interface. It is a proposed operating system interface standard based on the popular UNIX2 operating system; its main goal is POSIX.7 System Administration to support application portability at the source-code level. It is POSIX.8 Transparent File Access being standardized by the Computer Society of IEEE as the IEEE standard P1003, and also by ISO/IEC, as the POSIX.12 Protocol Independent Network Interfaces international standard ISO/IEC-9945. POSIX.15 Batch Queuing Extensions POSIX is an evolving group of standards, each of which POSIX.17 Directory Services covers different aspects of the operating systems. Some of these standards have already been approved, while others are a Approved IEEE standards b currently being developed. They can be grouped in three Approved ISO/IEC standard categories: 1) Base Standards: They define system interfaces related to different aspects of the operating system. The standard Table II. Additional POSIX Base Standards specifies the syntax and semantics of system interfaces so that application programs can directly invoke the operating P1224 Message Handling Services (X.400) system services. The standard does not specify how these P1224.1 X.400 Application Portability Interface services are to be implemented, just their semantics; system implementors can choose their implementation as long as P1238 Common OSI Application Portability Interface they follow the specification of the interface. Initially, the P1238.1 FTAM OSI Application Portability Interface base standards were developed for the C language, but now they are being specified as language-independent interfaces. P1201.1 Windowing Application Portability Interface Table I and Table II list the base standards that are P1201.2 Recommended Practice on Driveability currently being standardized under POSIX. 1 This work was supported in part by the Comisión Interministerial de Ciencia y Tecnología of the Spanish Government, under grants ROB91-0288 and ROB91-1553-E. 2 UNIX is a trademark of AT&T 2) Language bindings: These standards provide the actual Because of the need to achieve application portability for interfaces for different programming languages. The real-time systems, a real-time working group was established languages that are currently being used are C, Ada, in POSIX. This group is developing standards to add POSIX Fortran 77, and Fortran 90. Table III lists the POSIX (or UNIX) the OS services that are needed by real-time language bindings that are currently under development. applications. The charter of the POSIX Real-time Working Group is to "develop standards which are the minimum Table III. List of POSIX Language Bindings syntactic and semantic changes or additions to the POSIX standards to support portability of applications with real-time POSIX.5 Ada Bindingsa requirements." a POSIX.9 Fortran 77 Bindings Many real-time applications, such as small embedded POSIX.16 C Language Bindings systems, have special physical constraints that demand for operating systems with a reduced set of functionality. For POSIX.19 Fortran 90 Bindings example, many systems exist which cannot have a disk drive, POSIX.20 Ada Bindings to Real-time Extensions do not have a hardware memory management unit, and have a small amount of memory. For these systems it is necessary a Approved IEEE standards that the standard allows implementations to only support a particular subset of the POSIX functions. The subsets necessary for real-time applications are also being addressed by 3) Open Systems Environment. These standards include a the Real-time Working Group, which has specified four real- guide to the POSIX environment, and application profiles. time application environment profiles: for small embedded An application profile is a list of the POSIX standards that systems, real-time controllers, large embedded systems, and are required for a certain application environment, along large systems with real-time requirements. with the options and parameters of these standards whose support is required for that application environment. According to these requirements, the Real-time Working Application profiles are a very important means of Group is currently developing four standards, that we will achieving a small number of well-defined types of review in this paper: operating system implementations appropriate for particular application environments. Table IV shows the list POSIX.4: of standards that are being developed in this group. Real-time extensions. Defines interfaces to support the portability of applications with real-time requirements. Table IV. List of POSIX Application Environment Standards POSIX.4a POSIX.0 Guide to POSIX Open System Environment Threads extension. Defines the interfaces to support multiple threads of control inside each POSIX process. POSIX.10 Supercomputing Application Environment Profile POSIX.4b POSIX.11 Transaction Processing Application Additional real-time extensions. Defines interfaces to Environment Profile support additional real-time services. POSIX.13 Real-time Application Environment Profiles POSIX.13 POSIX.14 Multiprocessing Application Environment Real-time application environment profiles. Each profile Profile lists the services that are necessary for a particular application environment. POSIX.18 POSIX Platform Application Environment Profile The following sections discuss the most relevant aspects of each of these standards. The discussion is based on the status The POSIX standard is necessary because, although UNIX of these standards at the time this paper is being written. This is a de-facto standard, there are enough differences among the status corresponds to Draft 13 of POSIX.4 [10], Draft 6 of different implementations to make applications not be POSIX.4a [11], Draft 6 of POSIX.4b [12], and Draft 5 of completely portable. But, while a UNIX application may need POSIX.13 [13]. Since all these standards are still being some changes to be ported to a different platform, portability developed, changes made to them could affect the discussions of real-time applications is far more difficult, since there exist in this paper. However, we believe that the spirit of most of a large variety of real-time operating systems. UNIX is not a what is discussed here will apply to the final standards. real-time operating system, and there is no de-facto standard for these applications. II. REAL-TIME EXTENSIONS C. Process Synchronization This section discusses some of the most important features POSIX.4 defines functions to manage process of POSIX.4 [10], which is the part of POSIX that defines synchronization with counting semaphores. These semaphores system interfaces to support applications with real-time are identified by a name that belongs to an implementation- requirements. POSIX.4 is very near to its approval as a defined name space. This name space may or may not coincide standard. with the file name space. The counting semaphore is a common synchronization mechanism that allows mutually A. Real-time Process Scheduling exclusive access to shared resources, signaling and waiting among processes, and other synchronization requirements. One The base POSIX.1 standard [9] defines a model of of the most common uses of semaphores is to share data concurrent activities called processes, but does not specify any among processes, and this can be accomplished in POSIX.4 by scheduling policy nor any concept of priority. For real-time using shared memory objects (see Section II.D) together with applications to be portable it is necessary to specify some semaphores. scheduling policy suitable for real-time. POSIX.4 specifies three scheduling policies. Each process has a scheduling Unfortunately, the counting semaphores specified in attribute that can be set to any of the three policies: POSIX.4 do not prevent unbounded priority inversion [6]. Priority inversion occurs when a high priority process has to • SCHED_FIFO: This is a fixed-priority preemptive wait for a lower priority process to complete some action. scheduling policy, in which processes with the same Using appropriate protocols, priority inversion can be bounded priority are treated in first-in-first-out (FIFO) order. At by the duration of critical sections, that is, sections of code least 32 priority levels must be available for this policy. during which the process reserves a particular resource for exclusive use. However, with conventional semaphores • SCHED_RR: This policy is similar to SCHED_FIFO, but unbounded priority inversion may occur; this means that the uses a time-sliced (round robin) method to schedule delay experienced by high priority tasks is not bounded by the processes with the same
Recommended publications
  • Technical Standard

    Technical Standard

    Technical Standard X/Open Curses, Issue 7 The Open Group ©November 2009, The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners. Technical Standard X/Open Curses, Issue 7 ISBN: 1-931624-83-6 Document Number: C094 Published in the U.K. by The Open Group, November 2009. This standardhas been prepared by The Open Group Base Working Group. Feedback relating to the material contained within this standardmay be submitted by using the web site at http://austingroupbugs.net with the Project field set to "Xcurses Issue 7". ii Technical Standard 2009 Contents Chapter 1 Introduction........................................................................................... 1 1.1 This Document ........................................................................................ 1 1.1.1 Relationship to Previous Issues ......................................................... 1 1.1.2 Features Introduced in Issue 7 ........................................................... 2 1.1.3 Features Withdrawn in Issue 7........................................................... 2 1.1.4 Features Introduced in Issue 4 ........................................................... 2 1.2 Conformance............................................................................................ 3 1.2.1 Base Curses Conformance .................................................................
  • Synchronizing Threads with POSIX Semaphores

    Synchronizing Threads with POSIX Semaphores

    3/17/2016 POSIX Semaphores Synchronizing Threads with POSIX Semaphores 1. Why semaphores? 2. Posix semaphores are easy to use sem_init sem_wait sem_post sem_getvalue sem_destroy 3. Activities 1 2 Now it is time to take a look at some code that does something a little unexpected. The program badcnt.c creates two new threads, both of which increment a global variable called cnt exactly NITER, with NITER = 1,000,000. But the program produces unexpected results. Activity 1. Create a directory called posixsem in your class Unix directory. Download in this directory the code badcnt.c and compile it using gcc badcnt.c -o badcnt -lpthread Run the executable badcnt and observe the ouput. Try it on both tanner and felix. Quite unexpected! Since cnt starts at 0, and both threads increment it NITER times, we should see cnt equal to 2*NITER at the end of the program. What happens? Threads can greatly simplify writing elegant and efficient programs. However, there are problems when multiple threads share a common address space, like the variable cnt in our earlier example. To understand what might happen, let us analyze this simple piece of code: THREAD 1 THREAD 2 a = data; b = data; a++; b--; data = a; data = b; Now if this code is executed serially (for instance, THREAD 1 first and then THREAD 2), there are no problems. However threads execute in an arbitrary order, so consider the following situation: Thread 1 Thread 2 data a = data; --- 0 a = a+1; --- 0 --- b = data; // 0 0 --- b = b + 1; 0 data = a; // 1 --- 1 --- data = b; // 1 1 So data could end up +1, 0, -1, and there is NO WAY to know which value! It is completely non- deterministic! http://www.csc.villanova.edu/~mdamian/threads/posixsem.html 1/4 3/17/2016 POSIX Semaphores The solution to this is to provide functions that will block a thread if another thread is accessing data that it is using.
  • Openextensions POSIX Conformance Document

    Openextensions POSIX Conformance Document

    z/VM Version 7 Release 1 OpenExtensions POSIX Conformance Document IBM GC24-6298-00 Note: Before you use this information and the product it supports, read the information in “Notices” on page 73. This edition applies to version 7, release 1, modification 0 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2018-09-12 © Copyright International Business Machines Corporation 1993, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Tables........................................................................................................ ix About This Document............................................................................................xi Intended Audience......................................................................................................................................xi Conventions Used in This Document.......................................................................................................... xi Where to Find More Information.................................................................................................................xi Links to Other Documents and Websites.............................................................................................. xi How to Send Your Comments to IBM....................................................................xiii Summary of Changes for z/VM
  • Virtual Memory - Paging

    Virtual Memory - Paging

    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
  • So You Think You Know C? [Pdf]

    So You Think You Know C? [Pdf]

    So You Think You Know C? And Ten More Short Essays on Programming Languages by Oleksandr Kaleniuk Published in 2020 This is being published under the Creative Commons Zero license. I have dedicated this work to the public domain by waiving all of my rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. Table of Contents Introduction......................................................................................................... 4 So you think you know C?..................................................................................6 APL deserves its renaissance too.......................................................................13 Going beyond the idiomatic Python..................................................................30 Why Erlang is the only true computer language................................................39 The invisible Prolog in C++..............................................................................43 One reason you probably shouldn’t bet your whole career on JavaScript.........54 You don't have to learn assembly to read disassembly......................................57 Fortran is still a thing........................................................................................64 Learn you a Lisp in 0 minutes...........................................................................68 Blood, sweat,
  • X86 Memory Protection and Translation

    X86 Memory Protection and Translation

    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
  • Virtual Memory in X86

    Virtual Memory in X86

    Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 x86 Processor Modes • Real mode – walks and talks like a really old x86 chip • State at boot • 20-bit address space, direct physical memory access • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a.
  • Software Engineering Standards Introduction

    Software Engineering Standards Introduction

    6/21/2008 Software Engineering Standards Introduction 1028 9126 730 12207 9000 CMM 15288 CMMI J-016 1679 Outline 1. Definitions 2. Sources of Standards 3. Why Use Standards ? 4. ISO and Software Engineering Standards 5. IEEE Software Engineering Collection Sources: IEEE Standards, Software Engineering, Volume Three: Product Standards, Introduction to the1999 Edition, pages i to xxiii. Horch, J., ‘Practical Guide to Software Quality management’, Artech House, 1996, chap 2. Wells, J., ‘An Introduction to IEEE/EIA 12207’, US DoD, SEPO, 1999. Moore, J., ‘Selecting Software Engineering Standards’, QAI Conference, 1998. Moore, J., ‘The Road Map to Software Engineering: A Standards-Based Guide’, Wiley-IEEE Computer Society Press, 2006. Moore, J.,’An Integrated Collection of Software Engineering Standards’, IEEE Software, Nov 1999. Gray, L., ‘Guidebook to IEEE/EIA 12207 Standard for Information Technology, Software Life Cycle Processes’, Abelia Corporation, Fairfax, Virginia, 2000. Coallier, F.; International Standardization in Software and Systems Engineering, Crosstalk, February 2003, pp. 18-22. 6/21/2008 2 1 6/21/2008 Exemple d’un système complexe Système de transport aérien Système de transport Système de Transport Aérien terrestre Système de Système de gestion du trafic réservation aérien Système Système aéroportuaire de distribution du kérosène SystèmeSystème avionique avion Système de Système de gestion de la Structure vie à bord SystèmeSystème de de équipage propulsionpropulsion Système SystèmeNavigation de de SystèmeVisualisation Système de navigationsystem de visualisation contrôle de vol SystèmeSystème de de réception réception Système de GPSGPS transport terrestremaritime 6/21/2008 3 Toward a Software Engineering Profession • What does it take ? 1. Body of Knowledge (e.g. SWEBOK) 2.
  • JTC1 and SC22 - Terminology

    JTC1 and SC22 - Terminology

    JTC1 AD Hoc Terminology, August 2005 1 JTC1 and SC22 - Terminology Background Following my offer to collect together the definitions from SC22 standards, SC22 accepted my offer and appointed me as its terminology representative (I was later also asked to represent UK and BSI) on the JTC1 ad hoc group on terminology. These notes summarise the results of collecting the SC22 definitions, and my impressions of the JTC1 ad hoc group. Roger Scowen August 2005 A collection of definitions from SC22 standards SC22 asked me to prepare a collected terminology for SC22 containing the definitions from standards for which SC22 is responsible, and asked the project editors to send me the definitions in text form. Many, but not all, project editors did so. However there are sufficient for SC22 to judge whether to complete the list or abandon it as an interesting but unprofitable exercise. Adding definitions to the database The project editor of a standard typically sends the definitions from the standard as a Word file, but it may be plain text or in Latex or nroff format. These definitions are transformed into a uniform format by a series of global ‘find & replace’ operations to produce a Word file where each definition is represented as a row of a table with three columns: the term, its definition, and any notes and/or examples. It is often easier to check this has been accomplished by copying and pasting successive attempts into Excel than examining the Word file itself. Sometimes there are special cases such as exotic characters (for example Greek or mathematical characters), special fonts, illustrations, diagrams, or tables.
  • Operating Systems

    Operating Systems

    UC Santa Barbara Operating Systems Christopher Kruegel Department of Computer Science UC Santa Barbara http://www.cs.ucsb.edu/~chris/ Virtual Memory and Paging UC Santa Barbara • What if a program is too big to be loaded in memory • What if a higher degree of multiprogramming is desirable • Physical memory is split in page frames • Virtual memory is split in pages • OS (with help from the hardware) manages the mapping between pages and page frames 2 Mapping Pages to Page Frames UC Santa Barbara • Virtual memory: 64KB • Physical memory: 32KB • Page size: 4KB • Virtual memory pages: 16 • Physical memory pages: 8 3 Memory Management Unit UC Santa Barbara • Automatically performs the mapping from virtual addresses into physical addresses 4 Memory Management Unit UC Santa Barbara • Addresses are split into a page number and an offset • Page numbers are used to look up a table in the MMU with as many entries as the number of virtual pages • Each entry in the table contains a bit that states if the virtual page is actually mapped to a physical one • If it is so, the entry contains the number of physical page used • If not, a page fault is generated and the OS has to deal with it 5 Page Tables UC Santa Barbara • Page tables contain an entry for each virtual table • If virtual memory is big (e.g., 32 bit and 64 bit addresses) the table can become of unmanageable size • Solution: instead of keeping them in the MMU move them to main memory • Problem: page tables are used each time an access to memory is performed.
  • Lecture 15 15.1 Paging

    Lecture 15 15.1 Paging

    CMPSCI 377 Operating Systems Fall 2009 Lecture 15 Lecturer: Emery Berger Scribe: Bruno Silva,Jim Partan 15.1 Paging In recent lectures, we have been discussing virtual memory. The valid addresses in a process' virtual address space correspond to actual data or code somewhere in the system, either in physical memory or on the disk. Since physical memory is fast and is a limited resource, we use the physical memory as a cache for the disk (another way of saying this is that the physical memory is \backed by" the disk, just as the L1 cache is \backed by" the L2 cache). Just as with any cache, we need to specify our policies for when to read a page into physical memory, when to evict a page from physical memory, and when to write a page from physical memory back to the disk. 15.1.1 Reading Pages into Physical Memory For reading, most operating systems use demand paging. This means that pages are only read from the disk into physical memory when they are needed. In the page table, there is a resident status bit, which says whether or not a valid page resides in physical memory. If the MMU tries to get a physical page number for a valid page which is not resident in physical memory, it issues a pagefault to the operating system. The OS then loads that page from disk, and then returns to the MMU to finish the translation.1 In addition, many operating systems make some use of pre-fetching, which is called pre-paging when used for pages.
  • File Systems: Semantics & Structure What Is a File

    File Systems: Semantics & Structure What Is a File

    5/15/2017 File Systems: Semantics & Structure What is a File 11A. File Semantics • a file is a named collection of information 11B. Namespace Semantics • primary roles of file system: 11C. File Representation – to store and retrieve data – to manage the media/space where data is stored 11D. Free Space Representation • typical operations: 11E. Namespace Representation – where is the first block of this file 11L. Disk Partitioning – where is the next block of this file 11F. File System Integration – where is block 35 of this file – allocate a new block to the end of this file – free all blocks associated with this file File Systems Semantics and Structure 1 File Systems Semantics and Structure 2 Data and Metadata Sequential Byte Stream Access • File systems deal with two kinds of information int infd = open(“abc”, O_RDONLY); int outfd = open(“xyz”, O_WRONLY+O_CREATE, 0666); • Data – the contents of the file if (infd >= 0 && outfd >= 0) { – e.g. instructions of the program, words in the letter int count = read(infd, buf, sizeof buf); Metadata – Information about the file • while( count > 0 ) { e.g. how many bytes are there, when was it created – write(outfd, buf, count); sometimes called attributes – count = read(infd, inbuf, BUFSIZE); • both must be persisted and protected } – stored and connected by the file system close(infd); close(outfd); } File Systems Semantics and Structure 3 File Systems Semantics and Structure 4 Random Access Consistency Model void *readSection(int fd, struct hdr *index, int section) { struct hdr *head = &hdr[section];