Chapter 6, The Operating System Machine Level

Transcription

1 Chapter 6, The Operating System Machine Level 6.1 Virtual Memory 6.2 Virtual I/O Instructions 6.3 Virtual Instructions For Parallel Processing 6.4 Example Operating Systems 6.5 Summary Virtual Memory General Types: Paged Virtual Memory A program is treated as a sequential set of code addressed from 0 to N-1. Memory is defined as fixed length pages for mappings. Typical page sizes are from 512 Bytes to 64 kbytes, with 2 or 4 kbytes popular. The last page is not full. 1 of 30 ECE 3570

2 Segmented Virtual Memory A program is treated as multiple code segments (objects), each addressed from 0 to N. Code segments may be any size. Code segments are loaded into main memory when needed. Reorganizing memory allocation in the main memory may be required occasionally. 2 of 30 ECE 3570

3 Segmented-Paged Virtual Memory Memory Hierarchy Access Summary 3 of 30 ECE 3570

4 Virtual I/O Instructions For high-level, OS based computing (non-microcontroller) all I/O can be virtualized and treated as reading or writing a file. This can simplify the organization of I/O. The virtual I/O systems reads and writes logical records to and from a file.. Directory Management Instructions A directory is a file describing other files. Provide a means of organizing storage, providing metadata (data about the file/data), and provide file protection/security. 4 of 30 ECE 3570

5 Virtual Instructions for Parallel Processing Provide for the virtual or actual parallel execution of multiple processes or program threads. Process Creation Each process requires: state information to be maintained PC, PSW, stack pointer, registers, etc. an address space defined for program instructions and variables Processes must be created, monitored and terminated dynamically by the OS. Virtual instructions to control process execution may include: stop, restart, examine, and terminate. a child process spawned by a parent may use all instructions, otherwise only the OS can perform these operations 5 of 30 ECE 3570

6 Race Conditions A danger of parallel processing! The producer-consumer problem. (one of many defined and named problems) Insuring that the producer and consumer processing threads do not both suspend. When the buffer is empty, consumer must suspend When the buffer is full, the producer must suspend If producer = consumer +1, resume consumer If consumer = producer +1, resume producer 6 of 30 ECE 3570

7 A fatal flaw due to parallel, asynchronous operation In is owned/updated by the producer Out is owned/updated by the consumer If consumer completes current task, Out+1 makes In=Out while consumer completes work If producer completes task, In+1 making In=Out+1 time to wake up active consumer But if there was a race condition to read In and Out, the consumer could have read In=Out, skipped wake-up as it was awake and proceed to go to sleep forever! A problem of maintaining a consistent view of concurrent processes. To reduce the possibility of race conditions provide for strict memory consistency requirements use synchronization variables or processes (Semaphores) 7 of 30 ECE 3570

8 Process Synchronization Using Semaphores Storage variables that are centrally accessible allow multiple simultaneous reads provide for atomic writes (only accessible by one process during a read/modify/write) (suspend/sleep/halt causes the variable to be released) JAVA code examples provided for up and down and the elimination of the previous race condition. Another method that you may discover is called two-phase locking. Locks or access-rights may be granted or acquired in an acquisition phase. Once all required locks have been received, execution can be performed. After completion all locks are released before new locks are requested. If lacks are acquired canonically race conditions can be avoided Note: there are special restrictions to avoid a deadlock! 8 of 30 ECE 3570

9 Example OS UNIX/Linux All UNIX systems support POSIX based international standard most have additions! 9 of 30 ECE 3570

10 10 of 30 ECE 3570

11 11 of 30 ECE 3570

12 12 of 30 ECE 3570

13 The text uses SUN based Solaris as a reference The general structure of a typical UNIX system 13 of 30 ECE 3570

14 14 of 30 ECE 3570

15 Windows XP A 32-bit multiprogramming operating system. Supports multiple user processes, each with a full 32-bit demand-paged virtual address space. Modular kernel architecture with interactions based on a client-server model. A client sends a request to a server process The server does the work and returns a response to the client The hardware abstraction layer Simplify interfacing to hardware devices Abstract models may be used instead of the actual detail Kernel (resident in main memory, non-preemptive) Provides access to all hardware as required for operation Support interrupts, traps and exceptions Process scheduling, synchronization, multiprocessor synchronization and time management Make the rest of the OS hardware independent, 15 of 30 ECE 3570

16 The System Services/System Interface Provide an interface to the executive kernel. Accepts system calls for execution from the user. User programming environments reside above this level. Environmental subsystems layer to provide a system calling interface Keep the programmer s away from Microsoft s domain. -: Microsoft maintains system calls as proprietary and they are not standardized Application Programming Interface (API), what Microsoft allows you to know 16 of 30 ECE 3570

17 Examples of Virtual Memory Unix The address space for a single UNIX process. Data and stack are allowed to grow in opposite directions Files may be mapped into the address space for access. Multiple processes can map to the same file. If one of multiple processes attempts to write the file, a copy-on-write generates a private copy in which writing may be performed. 17 of 30 ECE 3570

18 Windows XP Virtual Memory Every process has its own virtual address space (32-bits 4 GB) that is demand-paged with a fixed 4 kb page size. Virtual pages are in one of three states: Free (cause page faults and page loading) Reserved (not available for mapping until reservation removed) Committed (once code is mapped to a page whether resident or not in Main memory) a shadow page is kept on the disk for every committed page Also access restrictions per page Read Write Executable Memory-mapped files are allowed versions are brought up-to-date when unmapped or explicitly flushed APIs for managing virtual memory 18 of 30 ECE 3570

19 Examples of Virtual I/O Unix Simple organization of the file system. everything is a file ordinary files special files - for accessing actual I/O devices file descriptor standard input, standard output, and standard error opened file identification directory root directory directories are also files (files of files) path absolute path relative path link 19 of 30 ECE 3570

20 Typical Unix Directory Structure 20 of 30 ECE 3570

21 Typical Unix Directory Management Calls Finding file information File names i-node 64byte block describes information about the file file type, file protection RWX RWX RWX (user-group-world access) number of directory entries (links to the file) owner s id owner s group file length in bytes 13 disk addresses (10) direct, (1) indirect block, (1) double and (1) triple indirect blocks time last read time last written time the I-node was last changed 21 of 30 ECE 3570

22 Windows XP Virtual File I/O File Allocation Table (FAT) - old MS-DOS (Win 95&98 and by initial install selection) NT File System (NTFS) - described in the text File is a linear sequence of bits accessed using APIs (nearest Unix equivalent shown) Principal Win32 API Funcrtions for File I/O Directory APIs Principal Win32 API Funcrtions for Directory Management Security Descriptor Access Control List (ACL) 22 of 30 ECE 3570

23 Finding file information Storage defined in Volumes. Each volume contains contains information for managing the information contained. Volume organized as a linear sequence of clusters. Main data structure in each volumes is the Master File Table (MFT) Standard information time stamps hard link count read-only and archive bits File Name Variable length up to 255 Unicode characters MS-DOS name 8.3 backward compatibility name Security Information security descriptor pointing to relevant part of centralized security information file Data small files have all data incorporated in data field larger files have pointers to clusters containing the data larger files additional entries can be chained to the available entries maximum file size 2 64 bytes 23 of 30 ECE 3570

24 Process management: This section is best dealt with in your Computer Sciences classes. The terminology has evolved but the concepts remain, so here is overview material used in my other classes to described process management and software structures that are managed. This is more of a Unix/Linux terminology discussion. Processes, Tasks and Threads A process is a program in execution. The abstract view of a process is a dynamic entity that requires four components; The program code (or an image of the executable code) The control state (part of process/program state or context) The data state (part of process/program state or context), and Process Status. Program Code Programmer s code, runtime support, library routines, and system functions that are or will execute. Control and Data States (the components of the process/program state or process context) The data state contains the set of all data variables and data values. Data variables are variable declared by the programmer to hold data values. The control state contains the set of all control variables and control values. Control variables hold control flow information that may or may not be explicitly declared. The simplest control variable for a process with a single thread of control is the program counter. Program variables define the set containing both control and data variables. The program state at time t is the sum of the data state at time t and the control state at time t. The process context is used to refer to all state and variables resident in the machine when the process is executing (context switching to move this information in and out of memory is regularly performed). 24 of 30 ECE 3570

25 Process Status/State The process status describes the current operational state of the process. A state transition diagram may be used to track a processes operating state, with the operating state defining the current process status. For example, where three simple states are used (running, blocked, and ready) the following state transition diagram could be used by the operating system. Process state transition diagram Andrew S. Tanenbaum, Modern Operating Systems, 2nd edition, Prentice Hall, ISBN: Another description of states is 25 of 30 ECE 3570

26 A 6-state process state transition diagram is shown in the text. Figure 2.4 The process state transition diagram Zombie: A completed or terminated process that has not been removed from memory. 26 of 30 ECE 3570

27 Process Descriptor and Process State Table The process descriptor is a data structure that resides in the kernel space and contains information required for the kernel to manage the process. This structure is also referred to as the process control block ( ). Required information includes: Process credentials: process identifier (PID), parent process identifier, user identifier, group identifier, etc. Process Status: current state of the process Context: the area holding the context of the process (where to save suspended program state information when suspended) Memory Map: size and access rights, memory pointers Per-Process information: as required for proper execution Global Data Structures: pointers to queues and tables managed by the kernel Process control information: Implementation and management of a process must consider the following aspects: execution mode/state, address space, context, process descriptor, and process control. The process state information may be contained in a process table. An example process table may contain of the following elements. Example Process Table Andrew S. Tanenbaum, Modern Operating Systems, 2nd edition, Prentice Hall, ISBN: of 30 ECE 3570

28 Execution Mode The operating system normally includes the following components: The kernel: the operating system program component that manages system resources, handles exceptions, and controls processes. A shell: a user interface to the operating system and/or the space in which a user program is allowed to execute a user process. Utilities: operating system software required or frequently used, such as compilers, editors, debuggers Process switching between two resident processes: process A execution, mode switching to kernel, process context switching, mode switching to process B execution. Process switching (with context switching) may be invoked by the user process (exceptions or system calls) or by asynchronous operations (timer interrupts, disk interrupts, OS etc.). Process context switching in this fashion may be a very slow operation (moving a lot of data). This is an example of a heavy-weight process (with process control block and context ). Light-Weight Processes and Threads A more efficient methodology is to allow a heavy-weight process to exist, but allow one or more light-weight process to execute within the process. The light-weight processes share the process context, can have its own context (but less required), and can execute threads without calling for a kernel context switch or other kernel support. Note: this is not exactly how the text defines it. 28 of 30 ECE 3570

29 Threads Each process may execute a single thread of control at one time. Multiple threads may exist within a process. Threads may share the resources of the process in which they run. Threads must have descriptor or state information (thread context): thread ID, thread specific stack, thread priority and status, and thread storage area (shared or unique). Thread management may be performed by the process and need not require kernel management. Solaris Thread Model Process P1 Process P2 Process P3 User Kernel Hardware = Process = Thread = Light Weight Process = Processor Figure 7.1 Sun Solaris Thread Figure User level threads executes within a process. Each process may execute one or more lightweight processes (LWP). The Kernel based LWP may also be referred to as Kernel level threads (old terminology). (New terminology would describe a kernel level thread as executing a kernel level interrupt or function). 29 of 30 ECE 3570

30 Each LWP may be responsible for multiple threads. The LWP execute as a virtual processor. They may have their own stack and context. The number of LWP allocated to a process is called the concurrency level of the process. It refers to how many threads may execute simultaneously. Each LWP can handle scheduling of threads at the User level The Kernel or OS schedules Processes or Multiple LWP to execute on a single or a pool of processors. Before LWP, a thread would be bound to and execute in a process. When the thread could not proceed, the thread would become blocked and the process would be suspended until the thread became unblocked. When multiple processes were available, the system could do something else (context switch to another process), but it takes kernel level operations to change processes. Still necessary when blocking calls by LWP to the Kernel are expected and processors are available for scheduling. With LWP, a process could more easily switch LWP context to allow the processor to continue operation. In addition, LWP could perform thread scheduling at the user level instead of performing the task at the kernel process level. As an added bonus, Thread and LWP require less storage and less time for creation, switching, and closing. Threads share the address space of a process: this includes code, data as required, and most of the process descriptor information. Terminology: Bound Threads: a thread that is bound to a particular LWP Unbounded Thread: a thread that resides in a thread pool that can be scheduled to execute on multiple LWPs. An access thread table would provide shared resources for execution. 30 of 30 ECE 3570