CSC 227 Operating Systems Assignment 1 Due date: Wednesday, July 3rd, 2019 (by 11:59pm) This is an individual assignment. The homework must be submitted electronically through LMS Part I (50%) The use of Virtualization nowadays is widespread. Cloud computing utilize virtualizations among other things to provide cloud services. You are asked to install Linux on top of a virtual machine. There are no restrictions on 1. Linux distribution 2. Virtual machine (VM) Write about your experience including (not limited to) the reasons of choosing the preferred VM, and the preferred Linux distribution (minimum of 150 words). Also, include some screenshots showing that you have successfully installed Linux on the top of VM. Part II (50%) 1. Using the installed Linux operating system (Part I), write a C program that defines a global variable that has a value (e.g., 100). Your program will create 3 processes: parent and only two child processes as shown in the figure below.  The parent process will simply print the value of the global variable.  The 1st child process will increment the global variable and print its new value.  The 2nd child process will decrement the global variable and print its new value. i) Discuss the order of the output from the parent and children processes. ii) Why the value of the global variable isn’t affected by the increment/decrement operations in other processes? You should submit your answers for the two questions above as well as your code and screenshots of your output. Parent child child 2. Using the installed Linux operating system (Part I), use “ltrace” with proper parameters to show the list of system calls used by your program. Discuss in details the system calls used by your program. Chapter 1: Introduction Operating System Concepts – 9th Edit9on Silberschatz, Galvin and Gagne ©2013 Chapter 1: Introduction  What Operating Systems Do  Computer-System Organization  Computer-System Architecture  Operating-System Structure  Operating-System Operations  Process Management  Memory Management  Storage Management  Protection and Security  Kernel Data Structures  Computing Environments  Open-Source Operating Systems Operating System Concepts – 9th Edition 1.2 Silberschatz, Galvin and Gagne ©2013 Objectives  To describe the basic organization of computer systems  To provide a grand tour of the major components of operating systems  To give an overview of the many types of computing environments  To explore several open-source operating systems Operating System Concepts – 9th Edition 1.3 Silberschatz, Galvin and Gagne ©2013 What is an Operating System?  A program that acts as an intermediary between a user of a computer and the computer hardware  Operating system goals:  Execute user programs and make solving user problems easier  Make the computer system convenient to use  Use the computer hardware in an efficient manner Operating System Concepts – 9th Edition 1.4 Silberschatz, Galvin and Gagne ©2013 Computer System Structure  Computer system can be divided into four components:  Hardware – provides basic computing resources   Operating system   Controls and coordinates use of hardware among various applications and users Application programs – define the ways in which the system resources are used to solve the computing problems of the users   CPU, memory, I/O devices Word processors, compilers, web browsers, database systems, video games Users  People, machines, other computers Operating System Concepts – 9th Edition 1.5 Silberschatz, Galvin and Gagne ©2013 Four Components of a Computer System Operating System Concepts – 9th Edition 1.6 Silberschatz, Galvin and Gagne ©2013 What Operating Systems Do  Depends on the point of view  Users want convenience, ease of use and good performance  Don’t care about resource utilization  But shared computer such as mainframe or minicomputer must keep all users happy  Users of dedicate systems such as workstations have dedicated resources but frequently use shared resources from servers  Handheld computers are resource poor, optimized for usability and battery life  Some computers have little or no user interface, such as embedded computers in devices and automobiles Operating System Concepts – 9th Edition 1.7 Silberschatz, Galvin and Gagne ©2013 Operating System Definition  OS is a resource allocator  Manages all resources  Decides between conflicting requests for efficient and fair resource use  OS is a control program  Controls execution of programs to prevent errors and improper use of the computer Operating System Concepts – 9th Edition 1.8 Silberschatz, Galvin and Gagne ©2013 Operating System Definition (Cont.)  No universally accepted definition  “Everything a vendor ships when you order an operating system” is a good approximation  But varies wildly  “The one program running at all times on the computer” is the kernel.  Everything else is either  a system program (ships with the operating system) , or  an application program. Operating System Concepts – 9th Edition 1.9 Silberschatz, Galvin and Gagne ©2013 Computer Startup  bootstrap program is loaded at power-up or reboot  Typically stored in ROM or EPROM, generally known as firmware  Initializes all aspects of system  Loads operating system kernel and starts execution Operating System Concepts – 9th Edition 1.10 Silberschatz, Galvin and Gagne ©2013 Computer System Organization  Computer-system operation  One or more CPUs, device controllers connect through common bus providing access to shared memory  Concurrent execution of CPUs and devices competing for memory cycles Operating System Concepts – 9th Edition 1.11 Silberschatz, Galvin and Gagne ©2013 Computer-System Operation  I/O devices and the CPU can execute concurrently  Each device controller is in charge of a particular device type  Each device controller has a local buffer  CPU moves data from/to main memory to/from local buffers  I/O is from the device to local buffer of controller  Device controller informs CPU that it has finished its operation by causing an interrupt Operating System Concepts – 9th Edition 1.12 Silberschatz, Galvin and Gagne ©2013 Common Functions of Interrupts  Interrupt transfers control to the interrupt service routine generally, through the interrupt vector, which contains the addresses of all the service routines  Interrupt architecture must save the address of the interrupted instruction  A trap or exception is a software-generated interrupt caused either by an error or a user request  An operating system is interrupt driven Operating System Concepts – 9th Edition 1.13 Silberschatz, Galvin and Gagne ©2013 Interrupt Handling  The operating system preserves the state of the CPU by storing registers and the program counter  Determines which type of interrupt has occurred:  polling  vectored interrupt system  Separate segments of code determine what action should be taken for each type of interrupt Operating System Concepts – 9th Edition 1.14 Silberschatz, Galvin and Gagne ©2013 Interrupt Timeline Operating System Concepts – 9th Edition 1.15 Silberschatz, Galvin and Gagne ©2013 I/O Structure  After I/O starts, control returns to user program only upon I/O completion  Wait instruction idles the CPU until the next interrupt  Wait loop (contention for memory access)  At most one I/O request is outstanding at a time, no simultaneous I/O processing  After I/O starts, control returns to user program without waiting for I/O completion  System call – request to the OS to allow user to wait for I/O completion  Device-status table contains entry for each I/O device indicating its type, address, and state  OS indexes into I/O device table to determine device status and to modify table entry to include interrupt Operating System Concepts – 9th Edition 1.16 Silberschatz, Galvin and Gagne ©2013 Storage Definitions and Notation Review The basic unit of computer storage is the bit. A bit can contain one of two values, 0 and 1. All other storage in a computer is based on collections of bits. Given enough bits, it is amazing how many things a computer can represent: numbers, letters, images, movies, sounds, documents, and programs, to name a few. A byte is 8 bits, and on most computers it is the smallest convenient chunk of storage. For example, most computers don’t have an instruction to move a bit but do have one to move a byte. A less common term is word, which is a given computer architecture’s native unit of data. A word is made up of one or more bytes. For example, a computer that has 64-bit registers and 64bit memory addressing typically has 64-bit (8-byte) words. A computer executes many operations in its native word size rather than a byte at a time. Computer storage, along with most computer throughput, is generally measured and manipulated in bytes and collections of bytes. A kilobyte, or KB, is 1,024 bytes a megabyte, or MB, is 1,0242 bytes a gigabyte, or GB, is 1,0243 bytes a terabyte, or TB, is 1,0244 bytes a petabyte, or PB, is 1,0245 bytes Computer manufacturers often round off these numbers and say that a megabyte is 1 million bytes and a gigabyte is 1 billion bytes. Networking measurements are an exception to this general rule; they are given in bits (because networks move data a bit at a time). Operating System Concepts – 9th Edition 1.17 Silberschatz, Galvin and Gagne ©2013 Storage Structure  Main memory – only large storage media that the CPU can access directly  Random access  Typically volatile  Secondary storage – extension of main memory that provides large nonvolatile storage capacity  Hard disks – rigid metal or glass platters covered with magnetic recording material  Disk surface is logically divided into tracks, which are subdivided into sectors  The disk controller determines the logical interaction between the device and the computer  Solid-state disks – faster than hard disks, nonvolatile  Various technologies  Becoming more popular Operating System Concepts – 9th Edition 1.18 Silberschatz, Galvin and Gagne ©2013 Storage Hierarchy  Storage systems organized in hierarchy  Speed  Cost  Volatility  Caching – copying information into faster storage system; main memory can be viewed as a cache for secondary storage  Device Driver for each device controller to manage I/O  Provides uniform interface between controller and kernel Operating System Concepts – 9th Edition 1.19 Silberschatz, Galvin and Gagne ©2013 Storage-Device Hierarchy Operating System Concepts – 9th Edition 1.20 Silberschatz, Galvin and Gagne ©2013 Caching  Important principle, performed at many levels in a computer (in hardware, operating system, software)  Information in use copied from slower to faster storage temporarily  Faster storage (cache) checked first to determine if information is there  If it is, information used directly from the cache (fast)  If not, data copied to cache and used there  Cache smaller than storage being cached  Cache management important design problem  Cache size and replacement policy Operating System Concepts – 9th Edition 1.21 Silberschatz, Galvin and Gagne ©2013 Direct Memory Access Structure  Used for high-speed I/O devices able to transmit information at close to memory speeds  Device controller transfers blocks of data from buffer storage directly to main memory without CPU intervention  Only one interrupt is generated per block, rather than the one interrupt per byte Operating System Concepts – 9th Edition 1.22 Silberschatz, Galvin and Gagne ©2013 How a Modern Computer Works A von Neumann architecture Operating System Concepts – 9th Edition 1.23 Silberschatz, Galvin and Gagne ©2013 Computer-System Architecture  Most systems use a single general-purpose processor  Most systems have special-purpose processors as well  Multiprocessors systems growing in use and importance  Also known as parallel systems, tightly-coupled systems  Advantages include:  1. Increased throughput 2. Economy of scale (can cost less than equivalent multiple single-processor systems: share recourses) 3. Increased reliability – graceful degradation or fault tolerance Two types: 1. Asymmetric Multiprocessing – each processor is assigned a specific task (boss-worker relationship). 2. Symmetric Multiprocessing – each processor performs all tasks (all processors are peers) Operating System Concepts – 9th Edition 1.24 Silberschatz, Galvin and Gagne ©2013 Symmetric Multiprocessing Architecture Operating System Concepts – 9th Edition 1.25 Silberschatz, Galvin and Gagne ©2013 A Dual-Core Design  Multi-chip and multicore  Systems containing all chips  Chassis containing multiple separate systems Operating System Concepts – 9th Edition 1.26 Silberschatz, Galvin and Gagne ©2013 Clustered Systems  Like multiprocessor systems, but multiple systems working together  Usually sharing storage via a storage-area network (SAN)  Provides a high-availability service which survives failures   Asymmetric clustering has one machine in hot-standby mode  Symmetric clustering has multiple nodes running applications, monitoring each other (more efficient than Asymmetric clustering) Some clusters are for high-performance computing (HPC)   Applications must be written to use parallelization Some have distributed lock manager (DLM) to avoid conflicting operations Operating System Concepts – 9th Edition 1.27 Silberschatz, Galvin and Gagne ©2013 Clustered Systems Operating System Concepts – 9th Edition 1.28 Silberschatz, Galvin and Gagne ©2013 Operating System Structure  Multiprogramming (Batch system) needed for efficiency  Single user cannot keep CPU and I/O devices busy at all times  Multiprogramming organizes jobs (code and data) so CPU always has one to execute  A subset of total jobs in system is kept in memory  One job selected and run via job scheduling  When it has to wait (for I/O for example), OS switches to another job  Timesharing (multitasking) is logical extension in which CPU switches jobs so frequently that users can interact with each job while it is running, creating interactive computing  Response time should be < 1 second  Each user has at least one program executing in memory process  If several jobs ready to run at the same time  CPU scheduling  If processes don’t fit in memory, swapping moves them in and out to run  Virtual memory allows execution of processes not completely in memory Operating System Concepts – 9th Edition 1.29 Silberschatz, Galvin and Gagne ©2013 Memory Layout for Multiprogrammed System Operating System Concepts – 9th Edition 1.30 Silberschatz, Galvin and Gagne ©2013 Operating-System Operations  Interrupt driven (hardware and software)  Hardware interrupt by one of the devices  Software interrupt (exception or trap):  Software error (e.g., division by zero)  Request for operating system service  Other process problems include infinite loop, processes modifying each other or the operating system Operating System Concepts – 9th Edition 1.31 Silberschatz, Galvin and Gagne ©2013  A properly designed operating system must ensure that an incorrect (or malicious) program cannot cause other programs to execute incorrectly.  Errors can occur in a multiprogramming system, where one erroneous program might modify another program, the data of another program, or even the operating system itself.  we must be able to distinguish between the execution of operating-system code and user defined code.  The approach taken by most computer systems is to provide hardware support that allows us to differentiate among various modes of execution. Operating System Concepts – 9th Edition 1.32 Silberschatz, Galvin and Gagne ©2013  At the very least, we need two separate modes of operation: user mode and kernel mode (also called supervisor mode, system mode, or privileged mode).  A bit, called the mode bit, is added to the hardware of the computer to indicate the current mode: kernel (0) or user (1).  Protection by designating some of the machine instructions that may cause harm as privileged instructions.  The hardware allows privileged instructions to be executed only in kernel mode. If an attempt is made to execute a privileged instruction in user mode, the hardware does not execute the instruction but rather treats it as illegal and traps it to the operating system.  Examples include I/O control, timer management, and interrupt management. Operating System Concepts – 9th Edition 1.33 Silberschatz, Galvin and Gagne ©2013 Operating-System Operations (cont.)  Dual-mode operation allows OS to protect itself and other system components  User mode and kernel mode  Mode bit provided by hardware Provides ability to distinguish when system is running user code or kernel code  Some instructions designated as privileged, only executable in kernel mode  System call changes mode to kernel, return from call resets it to user  More Modes: Increasingly CPUs support multi-mode operations  i.e. virtual machine manager (VMM) mode for guest VMs   In this mode, the VMM has more privileges than user processes but fewer than the kernel. Operating System Concepts – 9th Edition 1.34 Silberschatz, Galvin and Gagne ©2013 Transition from User to Kernel Mode  We must ensure that the operating system maintains control over the CPU.  Timer to prevent infinite loop / process hogging resources  Timer is set to interrupt the computer after some time period  Keep a counter that is decremented by the physical clock.  Operating system set the counter (privileged instruction)  When counter zero generate an interrupt  Set up before scheduling process to regain control or terminate program that exceeds allotted time Operating System Concepts – 9th Edition 1.35 Silberschatz, Galvin and Gagne ©2013 Process Management  A process is a program in execution. It is a unit of work within the system. Program is a passive entity, process is an active entity.  Process needs resources to accomplish its task  CPU, memory, I/O, files  Initialization data  Process termination requires reclaim of any reusable resources  Single-threaded process has one program counter specifying location of next instruction to execute  Process executes instructions sequentially, one at a time, until completion  Multi-threaded process has one program counter per thread  Typically system has many processes, some user, some operating system running concurrently on one or more CPUs  Concurrency by multiplexing the CPUs among the processes / threads Operating System Concepts – 9th Edition 1.36 Silberschatz, Galvin and Gagne ©2013 Process Management Activities The operating system is responsible for the following activities in connection with process management:  Creating and deleting both user and system processes  Suspending and resuming processes  Providing mechanisms for process synchronization  Providing mechanisms for process communication  Providing mechanisms for deadlock handling Operating System Concepts – 9th Edition 1.37 Silberschatz, Galvin and Gagne ©2013 Memory Management  To execute a program all (or part) of the instructions must be in memory  All (or part) of the data that is needed by the program must be in memory.  Memory management determines what is in memory and when  Optimizing CPU utilization and computer response to users  Memory management activities  Keeping track of which parts of memory are currently being used and by whom  Deciding which processes (or parts thereof) and data to move into and out of memory  Allocating and deallocating memory space as needed Operating System Concepts – 9th Edition 1.38 Silberschatz, Galvin and Gagne ©2013 Storage Management  OS provides uniform, logical view of information storage  Abstracts physical properties to logical storage unit - file  Each medium is controlled by device (i.e., disk drive, tape drive)  Varying properties include access speed, capacity, datatransfer rate, access method (sequential or random)  File-System management  Files usually organized into directories  Access control on most systems to determine who can access what  OS activities include  Creating and deleting files and directories  Primitives to manipulate files and directories Mapping files onto secondary storage  Backup files onto stable (non-volatile) storage media  Operating System Concepts – 9th Edition 1.39 Silberschatz, Galvin and Gagne ©2013 Mass-Storage Management  Usually disks used to store data that does not fit in main memory or data that must be kept for a “long” period of time  Proper management is of central importance  Entire speed of computer operation hinges on disk subsystem and its algorithms  OS activities  Free-space management  Storage allocation  Disk scheduling  Some storage need not be fast  Tertiary storage includes optical storage, magnetic tape  Still must be managed – by OS or applications  Varies between WORM (write-once, read-many-times) and RW (read-write) Operating System Concepts – 9th Edition 1.40 Silberschatz, Galvin and Gagne ©2013 Performance of Various Levels of Storage Movement between levels of storage hierarchy can be explicit or implicit Operating System Concepts – 9th Edition 1.41 Silberschatz, Galvin and Gagne ©2013 Migration of data “A” from Disk to Register  Multitasking environments must be careful to use most recent value, no matter where it is stored in the storage hierarchy  Multiprocessor environment must provide cache coherency in hardware such that all CPUs have the most recent value in their cache  Distributed environment situation even more complex  Several copies of a datum can exist  Various solutions covered in Chapter 17 Operating System Concepts – 9th Edition 1.42 Silberschatz, Galvin and Gagne ©2013 I/O Subsystem  One purpose of OS is to hide peculiarities of hardware devices from the user  This is usually done by I/O subsystems.  I/O subsystem responsible for  Memory management of I/O including buffering (storing data temporarily while it is being transferred), caching (storing parts of data in faster storage for performance), spooling (the overlapping of output of one job with input of other jobs)  General device-driver interface  Drivers for specific hardware devices Operating System Concepts – 9th Edition 1.43 Silberschatz, Galvin and Gagne ©2013 Protection and Security  Protection – any mechanism for controlling access of processes or users to resources defined by the OS  Security – defense of the system against internal and external attacks  Huge range, including denial-of-service, worms, viruses, identity theft, theft of service  Systems generally first distinguish among users, to determine who can do what  User identities (user IDs, security IDs) include name and associated number, one per user  User ID then associated with all files, processes of that user to determine access control  Group identifier (group ID) allows set of users to be defined and controls managed, then also associated with each process, file  Privilege escalation allows user to change to effective ID with more rights Operating System Concepts – 9th Edition 1.44 Silberschatz, Galvin and Gagne ©2013 Kernel Data Structures  Many similar to standard programming data structures  Singly linked list  Doubly linked list  Circular linked list Operating System Concepts – 9th Edition 1.45 Silberschatz, Galvin and Gagne ©2013 Kernel Data Structures  Binary search tree left shell reloaded At system startup Operating System Concepts – 9th Edition 2.27 running a program Silberschatz, Galvin and Gagne ©2013 Example: FreeBSD  Unix variant  Multitasking  User login -> invoke user’s choice of shell  Shell executes fork() system call to create process  Executes exec() to load program into process  Shell waits for process to terminate or continues with user commands  Process exits with:  code = 0 – no error  code > 0 – error code Operating System Concepts – 9th Edition 2.28 Silberschatz, Galvin and Gagne ©2013 System Programs  System programs provide a convenient environment for program development and execution. They can be divided into:  File manipulation  Status information sometimes stored in a File modification  Programming language support  Program loading and execution  Communications  Background services  Application programs  Most users’ view of the operation system is defined by system programs, not the actual system calls Operating System Concepts – 9th Edition 2.29 Silberschatz, Galvin and Gagne ©2013 System Programs  Provide a convenient environment for program development and execution  Some of them are simply user interfaces to system calls; others are considerably more complex  File management - Create, delete, copy, rename, print, dump, list, and generally manipulate files and directories  Status information  Some ask the system for info - date, time, amount of available memory, disk space, number of users  Others provide detailed performance, logging, and debugging information  Typically, these programs format and print the output to the terminal or other output devices  Some systems implement a registry - used to store and retrieve configuration information Operating System Concepts – 9th Edition 2.30 Silberschatz, Galvin and Gagne ©2013 System Programs (Cont.)  File modification  Text editors to create and modify files  Special commands to search contents of files or perform transformations of the text  Programming-language support - Compilers, assemblers, debuggers and interpreters sometimes provided  Program loading and execution- Absolute loaders, relocatable loaders, linkage editors, and overlay-loaders, debugging systems for higher-level and machine language  Communications - Provide the mechanism for creating virtual connections among processes, users, and computer systems  Allow users to send messages to one another’s screens, browse web pages, send electronic-mail messages, log in remotely, transfer files from one machine to another Operating System Concepts – 9th Edition 2.31 Silberschatz, Galvin and Gagne ©2013 System Programs (Cont.)  Background Services  Launch at boot time  Some for system startup, then terminate  Some from system boot to shutdown  Provide facilities like disk checking, process scheduling, error logging, printing  Run in user context not kernel context  Known as services, subsystems, daemons  Application programs     Don’t pertain to system Run by users Not typically considered part of OS Launched by command line, mouse click, finger poke Operating System Concepts – 9th Edition 2.32 Silberschatz, Galvin and Gagne ©2013 Operating System Design and Implementation  Design and Implementation of OS not “solvable”, but some approaches have proven successful  Internal structure of different Operating Systems can vary widely  Start the design by defining goals and specifications  Affected by choice of hardware, type of system  User goals and System goals  User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast (note these requirements are vague and may be interpreted in different ways i.e. not solvable)  System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient (again these requirements are vague and may be interpreted in different ways) Operating System Concepts – 9th Edition 2.33 Silberschatz, Galvin and Gagne ©2013 Operating System Design and Implementation (Cont.)  Specifying and designing an operating system is a highly creative task.  Although no textbook can tell you how to do it, general principles have been developed in the field of software engineering  Important principle to separate Policy: What will be done? (how long the timer is set for a particular user) Mechanism: How to do it? (e.g. the timer construct to protect CPU)  Mechanisms determine how to do something, policies decide what will be done  The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later (example – timer)  Specifying and designing an OS is highly creative task of software engineering Operating System Concepts – 9th Edition 2.34 Silberschatz, Galvin and Gagne ©2013 Implementation  Much variation  Early OSes in assembly language  Then system programming languages like Algol, PL/1  Now C, C++  Actually usually a mix of languages  Lowest levels in assembly  Main body in C  Systems programs in C, C++, scripting languages like PERL, Python, shell scripts  More high-level language easier to port to other hardware  But slower (because an expert assembly language expert can write more efficient code, however modern compilers can perform sophisticated optimization and produce efficient code)  Emulation can allow an OS to run on non-native hardware (emulators are programs that duplicate the functionality of one system on another system.) Operating System Concepts – 9th Edition 2.35 Silberschatz, Galvin and Gagne ©2013 Operating System Structure  General-purpose OS is very large program  It must be engineered carefully if it is to function properly and be modified easily.  A common approach is to partition the task into small components, or modules.  Each with carefully defined inputs, outputs, and functions.  Various ways to structure ones  Simple structure – MS-DOS  More complex -- UNIX  Layered – an abstrcation  Microkernel -Mach Operating System Concepts – 9th Edition 2.36 Silberschatz, Galvin and Gagne ©2013 Simple Structure -- MS-DOS  MS-DOS – written to provide the most functionality in the least space  Not divided into modules  Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated  For instance, application programs are able to access the basic I/O routines to write directly to the display and disk drives.  Such freedom leaves MSDOS vulnerable to errant (or malicious) programs, causing entire system crashes when user programs fail. Operating System Concepts – 9th Edition 2.37 Silberschatz, Galvin and Gagne ©2013 Non Simple Structure -- UNIX UNIX – limited by hardware functionality, the original UNIX operating system had limited structuring. The UNIX OS consists of two separable parts  Systems programs  The kernel  Consists of everything below the system-call interface and above the physical hardware  Provides the file system, CPU scheduling, memory management, and other operating-system functions;  a large number of functions for one level  This monolithic structure was difficult to implement and maintain.  It had a distinct performance advantage, however: there is very little overhead in the system call interface or in communication within the kernel. Operating System Concepts – 9th Edition 2.38 Silberschatz, Galvin and Gagne ©2013 Traditional UNIX System Structure Beyond simple but not fully layered Operating System Concepts – 9th Edition 2.39 Silberschatz, Galvin and Gagne ©2013 Layered Approach  The operating system is divided into a number of layers (levels), each built on top of lower layers. The bottom layer (layer 0), is the hardware; the highest (layer N) is the user interface.  With modularity, layers are selected such that each uses functions (operations) and services of only lower-level layers  This approach simplifies debugging and system verification.  A layer does not need to know how operations at a lower layer are implemented; it needs to know only what these operations do.  . Operating System Concepts – 9th Edition 2.40 Silberschatz, Galvin and Gagne ©2013 problems with the layered approach  The major difficulty is that layers need to be carefully defined  They tend to be less efficient than other types.  For instance, when a user program executes an I/O operation,  it executes a system call that is trapped to the I/O layer, which calls the memory-management layer, which in turn calls the CPU-scheduling layer, which is then passed to the hardware. Operating System Concepts – 9th Edition 2.41 Silberschatz, Galvin and Gagne ©2013 Microkernel System Structure  This method structures the operating system by removing all nonessential components from the kernel and  implementing them as system and user-level programs.  The result is a smaller kernel.  The kernel provides communication between the client program and the various services that are also running in user space.  Communication is provided through message passing.  The client program and service never interact directly. Rather, they communicate indirectly by exchanging messages with the microkernel. Operating System Concepts – 9th Edition 2.42 Silberschatz, Galvin and Gagne ©2013 Microkernel System Structure  Moves as much from the kernel into user space  Mach example of microkernel (developed by researchers at Carnegie Mellon Uni. in the mid-1980s)  Mac OS X kernel (Darwin) partly based on Mach  Communication takes place between user modules using message passing  Benefits:  Easier to extend a microkernel (All new services are added to user space and consequently do not require modification of the kernel)  Easier to port the operating system to new architectures ( a few modifications)  More reliable (less code is running in kernel mode)  More secure  Detriments:  Performance overhead of user space to kernel space communication Silberschatz, Galvin and Gagne ©2013 2.43 Operating System Concepts – 9 Edition th Microkernel System Structure Application Program File System messages Interprocess Communication Device Driver user mode messages memory managment CPU scheduling kernel mode microkernel hardware Operating System Concepts – 9th Edition 2.44 Silberschatz, Galvin and Gagne ©2013 Modules  the best current methodology for operating-system design  Many modern operating systems implement loadable kernel modules  The kernel provides core services  while other services are implemented dynamically, as the kernel is running.  Linking services dynamically is preferable to adding new features directly to the kernel, which would require recompiling the kernel every time a change was made.  Uses object-oriented approach  Each core component is separate  Each talks to the others over known interfaces  Each is loadable as needed within the kernel  Overall, similar to layers (has defined, protected interfaces) but with more flexible (any module can call any other module)  Linux, Solaris, etc Operating System Concepts – 9th Edition 2.45 Silberschatz, Galvin and Gagne ©2013 Solaris Modular Approach Operating System Concepts – 9th Edition 2.46 Silberschatz, Galvin and Gagne ©2013 Hybrid Systems  Most modern operating systems are actually not one pure model  Hybrid combines multiple approaches to address performance, security, usability needs  Linux and Solaris kernels in kernel address space, so monolithic (for performance reasons), plus modular for dynamic loading of functionality  Windows mostly monolithic, plus microkernel for different subsystem personalities  Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming environment  Below is kernel consisting of Mach microkernel and BSD Unix parts, plus I/O kit and dynamically loadable modules (called kernel extensions) Operating System Concepts – 9th Edition 2.47 Silberschatz, Galvin and Gagne ©2013 Mac OS X Structure graphical user interface Aqua application environments and services Java Cocoa Quicktime BSD kernel environment BSD Mach I/O kit Operating System Concepts – 9th Edition kernel extensions 2.48 Silberschatz, Galvin and Gagne ©2013 iOS  Apple mobile OS for iPhone, iPad  Structured on Mac OS X, added functionality  Does not run OS X applications natively  Also runs on different CPU architecture (ARM vs. Intel)  Cocoa Touch Objective-C API for developing apps  Media services layer for graphics, audio, video  Core services provides cloud computing, databases  Core operating system, based on Mac OS X kernel Operating System Concepts – 9th Edition 2.49 Silberschatz, Galvin and Gagne ©2013 Android  Developed by Open Handset Alliance (mostly Google)  Open Source  Similar stack to IOS  Based on Linux kernel but modified  Provides process, memory, device-driver management  Adds power management  Runtime environment includes core set of libraries and Dalvik virtual machine (designed for Android and is optimized for mobile devices with limited memory and CPU processing capabilities)  Apps developed in Java plus Android API  Java class files compiled to Java bytecode then translated to executable than runs in Dalvik VM  Libraries include frameworks for web browser (webkit), database (SQLite), multimedia, smaller libc Operating System Concepts – 9th Edition 2.50 Silberschatz, Galvin and Gagne ©2013 AndroidApplications Architecture Application Framework Libraries Android runtime SQLite openGL surface manager media framework webkit Core Libraries Dalvik virtual machine libc Linux kernel Operating System Concepts – 9th Edition 2.51 Silberschatz, Galvin and Gagne ©2013 Performance Tuning  Improve performance by removing bottlenecks  OS must provide means of computing and displaying measures of system behavior  For example, “top” program (for UNIX) or Windows Task Manager Operating System Concepts – 9th Edition 2.52 Silberschatz, Galvin and Gagne ©2013 Operating System Generation  Operating systems are designed to run on any of a class of machines; the system must be configured for each specific computer site  SYSGEN program obtains information concerning the specific configuration of the hardware system  Used to build system-specific compiled kernel or systemtuned  Can general more efficient code than one general kernel Operating System Concepts – 9th Edition 2.53 Silberschatz, Galvin and Gagne ©2013 System Boot  When power initialized on system, execution starts at a fixed memory location  Firmware ROM used to hold initial boot code  Operating system must be made available to hardware so hardware can start it  Small piece of code – bootstrap loader, stored in ROM or EEPROM locates the kernel, loads it into memory, and starts it  Sometimes two-step process where boot block at fixed location loaded by ROM code, which loads bootstrap loader from disk  Common bootstrap loader, GRUB, allows selection of kernel from multiple disks, versions, kernel options  Kernel loads and system is then running Operating System Concepts – 9th Edition 2.54 Silberschatz, Galvin and Gagne ©2013 End of Chapter 2 Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013 Chapter 3: Processes Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013 Chapter 3: Processes  Process Concept  Process Scheduling  Operations on Processes  Interprocess Communication Operating System Concepts – 9th Edition 3.2 Silberschatz, Galvin and Gagne ©2013 Objectives  To introduce the notion of a process -- a program in execution, which forms the basis of all computation  To describe the various features of processes, including scheduling, creation and termination, and communication  To explore interprocess communication using shared memory and message passing  To describe communication in client-server systems Operating System Concepts – 9th Edition 3.3 Silberschatz, Galvin and Gagne ©2013 Process Management  A process can be thought of as a program in execution.  A process will need certain resources—such as CPU time, memory, files, and I/O devices —to accomplish its task. These resources are allocated to the process either when it is created or while it is executing.  A process is the unit of work in most systems.  Two types of Processes  operating-system processes execute system code, and  user processes execute user code.  All these processes may execute concurrently.  The operating system is responsible for  the creation and deletion of both user and system processes;  The scheduling of processes; and  the provision of mechanisms for synchronization,  communication, and  deadlock handling for processes. Operating System Concepts – 9th Edition 3.4 Silberschatz, Galvin and Gagne ©2013 Process Concept  An operating system executes a variety of programs:  Batch system – jobs  Time-shared systems – user programs or tasks  Textbook uses the terms job and process almost interchangeably  Process – a program in execution; process execution must progress in sequential fashion  A program by itself is not a process.  A program is a passive entity, such as a file containing a list of instructions stored on disk (often called an executable file).  In contrast, a process is an active entity, with a program counter specifying the next instruction to execute and a set of associated resources.  A program becomes a process when an executable file is loaded into memory. Operating System Concepts – 9th Edition 3.5 Silberschatz, Galvin and Gagne ©2013  Multiple parts (of a process)  The program code, also called text section  Current activity including program counter, processor registers  Stack containing temporary data  Function parameters, return addresses, local variables  Data section containing global variables  Heap containing memory dynamically allocated during run time Operating System Concepts – 9th Edition 3.6 Silberschatz, Galvin and Gagne ©2013 Process in Memory Operating System Concepts – 9th Edition 3.7 Silberschatz, Galvin and Gagne ©2013 Process Concept (Cont.)  A program is loaded and Execution of program started via GUI mouse clicks, command line entry of its name, etc  One program can be several processes  Consider multiple users executing the same program (multiple copies)  Or the same user may invoke many copies of the web browser program  Each of these is a separate process; and  although the text sections are equivalent, the data, heap, and stack sections vary.  It is also common to have a process that spawns many processes as it runs. Operating System Concepts – 9th Edition 3.8 Silberschatz, Galvin and Gagne ©2013 Process State  As a process executes, it changes state  new: The process is being created  running: Instructions are being executed  waiting: The process is waiting for some event to occur  ready: The process is waiting to be assigned to a processor  terminated: The process has finished execution Operating System Concepts – 9th Edition 3.9 Silberschatz, Galvin and Gagne ©2013 Diagram of Process State Operating System Concepts – 9th Edition 3.10 Silberschatz, Galvin and Gagne ©2013 Process Control Block (PCB) Information associated with each process (also called task control block)  Process state – running, waiting, etc  Program counter – location of instruction to next execute  CPU registers – contents of all process- centric registers  CPU scheduling information- priorities, scheduling queue pointers (chap 6)  Memory-management information – memory allocated to the process (chap 8)  Accounting information – CPU used, clock time elapsed since start, time limits  I/O status information – I/O devices allocated to process, list of open files Operating System Concepts – 9th Edition 3.11 Silberschatz, Galvin and Gagne ©2013 CPU Switch From Process to Process Operating System Concepts – 9th Edition 3.12 Silberschatz, Galvin and Gagne ©2013 Threads  So far, process has a single thread of execution  The user cannot simultaneously type in characters and run the spell checker within the same process, for example.  Modern operating systems extended the process concept to allow a process to have multiple threads of execution and thus to perform more than one task at a time.  Consider having multiple program counters per process  Multiple locations can execute at once  Multiple threads of control -> threads  Must then have storage for thread details, multiple program counters in PCB  Other changes are also needed to support threads.  See next chapter (chap 4) Operating System Concepts – 9th Edition 3.13 Silberschatz, Galvin and Gagne ©2013 Process Representation in Linux Represented by the C structure task_struct pid t_pid; /* process identifier */ long state; /* state of the process */ unsigned int time_slice /* scheduling information */ struct task_struct *parent; /* this process’s parent */ struct list_head children; /* this process’s children */ struct files_struct *files; /* list of open files */ struct mm_struct *mm; /* address space of this process */ Operating System Concepts – 9th Edition 3.14 Silberschatz, Galvin and Gagne ©2013 Process Scheduling  Maximize CPU use, quickly switch processes onto CPU for time sharing  Process scheduler selects among available processes for next execution on CPU  Maintains scheduling queues of processes  Job queue – set of all processes in the system  Ready queue – set of all processes residing in main memory, ready and waiting to execute  Device queues – set of processes waiting for an I/O device (Each device has its own device queue)  Processes migrate among the various queues Operating System Concepts – 9th Edition 3.15 Silberschatz, Galvin and Gagne ©2013 Ready Queue And Various I/O Device Queues Operating System Concepts – 9th Edition 3.16 Silberschatz, Galvin and Gagne ©2013 Representation of Process Scheduling  Queueing diagram represents queues, resources, flows Operating System Concepts – 9th Edition 3.17 Silberschatz, Galvin and Gagne ©2013 Schedulers     Short-term scheduler (or CPU scheduler) – selects which process should be executed next and allocates CPU  Sometimes the only scheduler in a system  Short-term scheduler is invoked frequently (milliseconds)  (must be fast) Long-term scheduler (or job scheduler) – selects which processes should be brought into the ready queue  Long-term scheduler is invoked infrequently (seconds, minutes)  (may be slow)  The long-term scheduler controls the degree of multiprogramming (the number of processes in memory) Processes can be described as either:  I/O-bound process – spends more time doing I/O than computations, many short CPU bursts  CPU-bound process – spends more time doing computations; few very long CPU bursts Long-term scheduler strives for good process mix Operating System Concepts – 9th Edition 3.18 Silberschatz, Galvin and Gagne ©2013 Addition of Medium Term Scheduling  Medium-term scheduler can be added if degree of multiple programming needs to decrease  Remove process from memory, store on disk, bring back in from disk to continue execution: swapping  Swapping may be necessary  to improve the process mix (of CPU bound and I/O bound)  or because a change in memory requirements has overcommitted available memory, requiring memory to be freed up. Operating System Concepts – 9th Edition 3.19 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9th Edition 3.20 Silberschatz, Galvin and Gagne ©2013 Multitasking in Mobile Systems  Some mobile systems (e.g., early version of iOS) allow only one process to run, others suspended  Due to screen real estate, user interface limits iOS provides for a  Single foreground process- controlled via user interface  Multiple background processes– in memory, running, but not on the display, and with limits  Limits include single, short task, receiving notification of events, specific long-running tasks like audio playback  Apple probably limits multitasking due to battery life and memory use concerns.  Android does not place such constraints on the types of applications that can run in the background  Android runs foreground and background, with fewer limits  Background process uses a service to perform tasks (a separate application component that runs on behalf of the background process.) Operating System Concepts – 9th Edition 3.21 Silberschatz, Galvin and Gagne ©2013 Multitasking in Mobile Systems cont.  Consider a streaming audio application:  if the application moves to the background, the service continues to send audio files to the audio device driver on behalf of the background application.  Service can keep running even if background process is suspended  Service has no user interface, small memory use Operating System Concepts – 9th Edition 3.22 Silberschatz, Galvin and Gagne ©2013 Context Switch  When CPU switches to another process, the system must save the state (in its PCB) of the old process and load the saved state for the new process via a context switch  Context of a process represented in the PCB  Context-switch time is overhead; the system does no useful work while switching  The more complex the OS and the PCB  the longer the context switch  Time dependent on hardware support  Some hardware (e.g. Sun UltraSPARC) provides multiple sets of registers per CPU  multiple contexts loaded at once.  A context switch here simply requires changing the pointer to the current register set. Operating System Concepts – 9th Edition 3.23 Silberschatz, Galvin and Gagne ©2013 Operations on Processes  System must provide mechanisms for:  process creation,  process termination,  and so on as detailed next Operating System Concepts – 9th Edition 3.24 Silberschatz, Galvin and Gagne ©2013 Process Creation  Parent process create children processes, which, in turn create other processes, forming a tree of processes  A child process will need certain resources (CPU time, memory, files, I/O devices)  Generally, process identified and managed via a process identifier (pid)  Resource sharing options  Parent and children share all resources  Children share subset of parent’s resources  Parent and child share no resources (the child process obtains its resources directly from the operating system)  Execution options  Parent and children execute concurrently  Parent waits until children terminate Operating System Concepts – 9th Edition 3.25 Silberschatz, Galvin and Gagne ©2013 A Tree of Processes in Linux init pid = 1 login pid = 8415 khelper pid = 6 bash pid = 8416 ps pid = 9298 Operating System Concepts – 9th Edition sshd pid = 3028 kthreadd pid = 2 pdflush pid = 200 sshd pid = 3610 tcsch pid = 4005 emacs pid = 9204 3.26 Silberschatz, Galvin and Gagne ©2013 Process Creation (Cont.)  Address space  Child duplicate of parent  Child has a program loaded into it  UNIX examples  fork() system call creates new process  exec() system call used after a fork() to replace the process’ memory space with a new program Operating System Concepts – 9th Edition 3.27 Silberschatz, Galvin and Gagne ©2013 C Program Forking Separate Process Operating System Concepts – 9th Edition 3.28 Silberschatz, Galvin and Gagne ©2013 Creating a Separate Process via Windows API Operating System Concepts – 9th Edition 3.29 Silberschatz, Galvin and Gagne ©2013 Process Termination  Process executes last statement and then asks the operating system to delete it using the exit() system call.  Returns status data from child to parent (via wait())  Process’ resources are deallocated by operating system  Parent may terminate the execution of children processes using the abort() system call. Some reasons for doing so:  Child has exceeded allocated resources  Task assigned to child is no longer required  The parent is exiting and the operating systems does not allow a child to continue if its parent terminates Operating System Concepts – 9th Edition 3.30 Silberschatz, Galvin and Gagne ©2013 Process Termination  Some operating systems do not allow child to exists if its parent has terminated. If a process terminates, then all its children must also be terminated.  cascading termination. All children, grandchildren, etc. are terminated.  The termination is initiated by the operating system.  The parent process may wait for termination of a child process by using the wait()system call. The call returns status information and the pid of the terminated process pid = wait(&status);  If a process terminates but has no parent waiting (did not invoke wait()) process is a zombie (because its entry in the process table entry continues to exist).  If parent terminated without invoking wait , process is an orphan (in Linux and Unix the init process becomes the parent which periodically invokes wait(), to allow the exit status of the orphan to be collected and thus to release the orphan’s process table entry) Operating System Concepts – 9th Edition 3.31 Silberschatz, Galvin and Gagne ©2013 Multiprocess Architecture – Chrome Browser  Many web browsers ran as single process (some still do)  If one web site causes trouble, entire browser can hang or crash  Google Chrome Browser is multiprocess with 3 different types of processes:  Browser process manages user interface, disk and network I/O  Renderer process renders web pages, deals with HTML, Javascript. A new renderer created for each website opened   Runs in sandbox restricting disk and network I/O, minimizing effect of security exploits Plug-in process for each type of plug-in Operating System Concepts – 9th Edition 3.32 Silberschatz, Galvin and Gagne ©2013 Interprocess Communication  Processes within a system may be independent or cooperating  Cooperating process can affect or be affected by other processes, including sharing data  Reasons for cooperating processes:  Information sharing (e.g. a shared file between several users)  Computation speedup (to break a task into several tasks to run them n parallel)  Modularity (dividing the systems functions into separate processes)  Convenience (For instance, a user may be editing, listening to music, and compiling in parallel) Operating System Concepts – 9th Edition 3.33 Silberschatz, Galvin and Gagne ©2013  Cooperating processes need interprocess communication (IPC) mechanism that will allow them to exchange data and information.  Two models of IPC   Shared memory  A region of memory that is shared by cooperating processes is established.  Processes can then exchange information by reading and writing data to the shared region Message passing  communication takes place by means of messages exchanged between the cooperating processes  Useful for exchanging smaller amounts of data, because no conflicts need be avoided and  easier to implement.  )Shared memory can be faster than message passing, since message- passing systems are typically implemented using system calls (time consuming)  However recent research show several cores Silberschatz, Galvin and Gagne ©2013 3.34 that in systems with Operating System Concepts – 9th Edition Communications Models (a) Message passing. Operating System Concepts – 9th Edition (b) shared memory. 3.35 Silberschatz, Galvin and Gagne ©2013 Producer-Consumer Problem  Paradigm for cooperating processes, producer process produces information that is consumed by a consumer process  E.g., a compiler produces code and the assembler consumes it  Client-server metaphor  unbounded-buffer places no practical limit on the size of the buffer (the consumer may have to wait but the producer does not have to wait)  bounded-buffer assumes that there is a fixed buffer size (both may have to wait; the producer has to wait if the buffer is full, while the consumer has to wait if the buffer is empty) Operating System Concepts – 9th Edition 3.36 Silberschatz, Galvin and Gagne ©2013  The shared buffer is implemented as a circular array with  two logical pointers:  The variable in and out. in points to the next free position in the buffer;  out points to the first full position in the buffer.  The buffer is empty when in == out;  the buffer is full when ((in + 1)% BUFFER SIZE) ==out. Operating System Concepts – 9th Edition 3.37 Silberschatz, Galvin and Gagne ©2013 Bounded-Buffer – Shared-Memory Solution  Shared data #define BUFFER_SIZE 10 typedef struct { . . . } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0;  Solution is correct, but can only use BUFFER_SIZE-1 elements Operating System Concepts – 9th Edition 3.38 Silberschatz, Galvin and Gagne ©2013 Bounded-Buffer – Producer item next_produced; while (true) { /* produce an item in next produced */ while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; } Operating System Concepts – 9th Edition 3.39 Silberschatz, Galvin and Gagne ©2013 Bounded Buffer – Consumer item next_consumed; while (true) { while (in == out) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; /* consume the item in next consumed */ } Operating System Concepts – 9th Edition 3.40 Silberschatz, Galvin and Gagne ©2013 Interprocess Communication – Shared Memory  An area of memory shared among the processes that wish to communicate  The communication is under the control of the users processes not the operating system.  Major issues is to provide mechanism that will allow the user processes to synchronize their actions when they access shared memory (i.e. how can they access the shared buffer concurrently; solution in chap 5)  Synchronization is discussed in great details in Chapter 5. Operating System Concepts – 9th Edition 3.41 Silberschatz, Galvin and Gagne ©2013 Interprocess Communication – Message Passing  Message passing provides a mechanism to allow processes to communicate and to synchronize their actions without sharing the same address space.  It is particularly useful in a distributed environment,  where the communicating processes may reside on different computers connected by a network.  For example, an Internet chat program Operating System Concepts – 9th Edition 3.42 Silberschatz, Galvin and Gagne ©2013 Interprocess Communication – Message Passing  Mechanism for processes to communicate and to synchronize their actions  Message system – processes communicate with each other without resorting to shared variables  IPC facility provides two operations: send(message)  receive(message)   The message size is either fixed or variable  Fixed-sized implementation is straightforward; however, it makes the task of programming more difficult  Variable length messages require a more complex system level implementation, but the programming task becomes simpler)  A common tradeoff in OS design Operating System Concepts – 9th Edition 3.43 Silberschatz, Galvin and Gagne ©2013 End of Chapter 3 Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
Purchase answer to see full attachment