Lecture 1 Introduction to OS PDF

Operating Systems: Internals Chapter 2 and Design Principles Operating System Overview...

Operating Systems: Internals Chapter 2 and Design Principles Operating System Overview Ninth Edition By William Stallings © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Operating System ◼A program that controls the execution of application programs ◼ An interface between applications and hardware Main objectives of an OS: Convenience Efficiency Ability to evolve © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Application programs Application programming interface Application Libraries/utilities Software binary interface Operating system I nstruction Set Architecture Execution hardware M emory System interconnect translation Hardware (bus) I /O devices M ain and memory networking Figure 2.1 Computer Hardware and Software Structure © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Operating System Services ◼ Program development ◼ Program execution ◼ Access I/O devices ◼ Controlled access to files ◼ System access ◼ Error detection and response ◼ Accounting © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Key Interfaces ◼ Instruction set architecture (ISA) : The ISA defines the repertoire of machine language instructions that a computer can follow. This interface is the boundary between hardware and software ◼ Application binary interface (ABI) : The ABI defines the system call interface to the operating system and the hardware resources and services available in a system through the user ISA. ◼ Application programming interface (API) :The API gives a program access to the hardware resources and services available in a system through the user ISA supplemented with high-level language (HLL) library calls. Any system calls are usually performed through libraries. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  The Operating System as Resource Manager ◼ The OS is responsible for controlling the use of a computer’s resources, such as I/O, main and secondary memory, and processor execution time. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Operating System as Resource Manager ◼ Functions in the same way as ordinary computer software ◼ Program, or suite of programs, executed by the processor ◼ Frequently relinquishes control and must depend on the processor to allow it to regain control © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Computer System I /O Devices M emory Operating I /O Controller Printers, System keyboards, Software digital camera, I /O Controller etc. Programs and Data I /O Controller Processor Processor Storage OS Programs Data Figure 2.2 The Operating System as Resource M anager The main resources managed by the OS. A portion of the OS is in main memory. This includes the kernel , or nucleus , which contains the most frequently used functions in the OS and, at a given time, other portions of the OS currently in use. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Evolution of Operating Systems ▪ A major OS will evolve over time for a number of reasons: Hardware upgrades New types of hardware New services Fixes © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Evolution of Operating Systems ▪ Stages include: Time Sharing Multiprogrammed Systems Batch Systems Simple Batch Systems Serial Processing © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Serial Processing Earliest Computers: Problems: ◼ Scheduling: ◼ No operating system ◼ Most installations used a ◼ Programmers interacted hardcopy sign-up sheet to directly with the computer reserve computer time hardware ◼ Time allocations could ◼ Computers ran from a console run short or long, with display lights, toggle resulting in wasted switches, some form of input computer time device, and a printer ◼ Setup time ◼ Users have access to the computer in “series” ◼ A considerable amount of time was spent on setting up the program to run © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Simple Batch Systems ◼ Early computers were very expensive ◼ Important to maximize processor utilization ◼ Monitor ◼ User no longer has direct access to processor ◼ Job is submitted to computer operator who batches them together and places them on an input device ◼ Program branches back to the monitor when finished © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Monitor Point of View I nterrupt ◼ Monitor controls the sequence Processing Device of events M onitor Drivers Job Sequencing ◼ Resident Monitor is software Control Language always in memory Boundary I nterpreter ◼ Monitor reads in job and gives control User Program Area ◼ Job returns control to monitor Figure 2.3 M emory Layout for a Resident M onitor © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Processor Point of View ◼ Processor executes instruction from the memory containing the monitor ◼ Executes the instructions in the user program until it encounters an ending or error condition ◼ “Control is passed to a job” means processor is fetching and executing instructions in a user program ◼ “Control is returned to the monitor” means that the processor is fetching and executing instructions from the monitor program © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Job Control Language (JCL) Special type of programming language used to provide instructions to the monitor //COBBSTEP JOB CLASS=6,NOTIFY=&SYSUID // //STEP10 EXEC PGM=MYPROG,PARM=ACCT5000 //STEPLIB DD DSN=MYDATA.URMI.LOADLIB, DISP=SHR What compiler to use //INPUT1 DD DSN=MYDATA.URMI.INPUT,DISP=SHR //OUT1 DD SYSOUT=* //OUT2 DD SYSOUT=* //SYSIN DD * //CUST1 1000 //CUST2 1001 /* What data to use © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Desirable Hardware Features by the monitor Memory protection While the user program is executing, it must not alter the memory area containing the monitor Timer Prevents a job from monopolizing the system Privileged instructions Can only be executed by the monitor Interrupts Gives OS more flexibility in controlling user programs © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Modes of Operation User Mode Kernel Mode User program executes in Monitor executes in kernel user mode mode Certain areas of memory are Privileged instructions may protected from user access be executed Certain instructions may not Protected areas of memory be executed may be accessed © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Simple Batch System Overhead ◼ Processor time alternates between execution of user programs and execution of the monitor ◼ Sacrifices: ◼ Some main memory is now given over to the monitor ◼ Some processor time is consumed by the monitor ◼ Despite overhead, the simple batch system improves utilization of the computer © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Multiprogrammed Batch Systems Even with the automatic job sequencing provided by a simple batch OS, the I/O devices processor is often idle. are slow compared The problem is that I/O devices are slow to processor compared to the processor. Even with automatic job sequencing Processor is often idle © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Read one record from file 15 µs Execute 100 instructions 1 µs Write one record to file 15 µs TOTAL 31 µs 1 Percent CPU Utilization = = 0.032 = 3.2% 31 Figure 2.4 System Utilization Example © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Uniprogramming Program A Run Wait Run Wait Time (a) Uniprogramming The processor spends a certain amount of time executing, until it reaches Program A an I/O instruction; Run Wait it must Run then wait until Wait that I/O instruction concludes before proceeding Program B Wait Run Wait Run Wait © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Program A Run Wait Run Wait Multiprogramming Time (a) Uniprogramming Program A Run Wait Run Wait Program B Wait Run Wait Run Wait Run Run Run Run Combined Wait Wait A B A B Time (b) M ultiprogramming with two programs ◼ There must be enough memory to hold the OS (resident monitor) and one user Program A program Run Wait Run Wait ◼ When one job needs to wait for I/O, the processor can switch to the other job, which is likely not waiting Program B for I/ORun Wait Wait Run Wait © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Program B Wait Run Wait Run Wait Run Run Run Run Multiprogramming Combined Wait Wait A B A B Time (b) M ultiprogramming with two programs Program A Run Wait Run Wait Program B Wait Run Wait Run Wait Program C Wait Run Wait Run Wait Run Run Run Run Run Run Combined Wait Wait A B C A B C Time (c) M ultiprogramming with three programs Figure 2.5 M ultiprogramming Example ◼ Also known as multitasking ◼ Memory is expanded to hold three, four, or more programs and switch among all of them © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Multiprogramming Example JOB1 JOB2 JOB3 Type of job Heavy compute Heavy I/O Heavy I/O Duration 5 min 15 min 10 min M emory required 50 M 100 M 75 M Need disk? No No Yes Need terminal? No Yes No Need printer? No No Yes Table 2.1 Sample Program Execution Attributes © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Uniprogramming M ultiprogramming Processor use 20% 40% M emory use 33% 67% Disk use 33% 67% Printer use 33% 67% Elapsed time 30 min 15 min Throughput 6 jobs/hr 12 jobs/hr M ean response time 18 min 10 min Table 2.2 Effects of Multiprogramming on Resource Utilization © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  100% 100% CPU CPU 0% 0% 100% 100% M emory M emory 0% 0% 100% 100% Disk Disk 0% 0% 100% 100% Terminal Terminal 0% 0% 100% 100% Printer Printer 0% 0% Job History Job History JOB1 JOB1 JOB2 JOB3 JOB2 0 5 10 15 20 25 30 minutes JOB3 0 5 10 15 time minutes time (a) Uniprogramming (b) M ultiprogramming Figure 2.6 Utilization Histograms © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Time-Sharing Systems ◼ Can be used to handle multiple interactive jobs ◼ Processor time is shared among multiple users ◼ Multiple users simultaneously access the system through terminals, with the OS interleaving the execution of each user program in a short burst or quantum of computation © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Batch M ultiprogramming Time Sharing Principal objective Maximize processor use Minimize response time Source of directives to Job control language Commands entered at the operating system commands provided with the terminal job Table 2.3 Batch Multiprogramming versus Time Sharing © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Compatible Time-Sharing System (CTSS) ◼ One of the first time-sharing operating systems ◼ Developed at MIT by a group known as Project MAC ◼ The system was first developed for the IBM 709 in 1961 ◼ Ran on a computer with 32,000 36-bit words of main memory, with the resident monitor consuming 5000 of that ◼ Utilized a technique known as time slicing ◼ System clock generated interrupts at a rate of approximately one every 0.2 seconds ◼ At each clock interrupt the OS regained control and could assign the processor to another user ◼ Thus, at regular time intervals the current user would be preempted and another user loaded in ◼ To preserve the old user program status for later resumption, the old user programs and data were written out to disk before the new user programs and data were read in ◼ Old user program code and data were restored in main memory when that program was next given a turn © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  0 0 0 M onitor M onitor M onitor 5000 5000 5000 JOB 3 10000 JOB 1 JOB 2 (JOB 2) 20000 Free 25000 25000 Free Free 32000 32000 32000 (a) (b) (c) 0 0 0 M onitor M onitor M onitor 5000 5000 5000 JOB 4 JOB 1 15000 JOB 2 (JOB 1) 20000 20000 (JOB 2) (JOB 2) 25000 25000 25000 Free Free Free 32000 32000 32000 (d) (e) (f) Figure 2.7 CTSS Operation When control was to be assigned to an interactive user, the user’s program and data were loaded into the remaining 27,000 words of main memory To minimize disk traffic, user memory was only written out when the incoming program would overwrite it. This principle is illustrated in Figure 2.7. Assume that there are four interactive users with the following memory requirements, in words: JOB1: 15,000 JOB2: 20,000 JOB3: 5000 JOB4: 10,000 © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Major Achievements ◼ Operating Systems are among the most complex pieces of software ever developed ◼ Major advances in development include: ◼ Processes ◼ Memory management ◼ Information protection and security ◼ Scheduling and resource management ◼ System structure © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Process ◼ Fundamental to the structure of operating systems A process can be defined as: A program in execution An instance of a running program The entity that can be assigned to, and executed on, a processor A unit of activity characterized by a single sequential thread of execution, a current state, and an associated set of system resources © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Memory Management ◼ The OS has five principal storage management responsibilities: Automatic Support of Protection Process allocation Long-term modular and access isolation and storage programming control management © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Information Protection and Security ◼ The nature of the threat that concerns an organization will Main vary greatly issues Availability depending on the circumstances ◼ The problem involves Authenticity Confidentiality controlling access to computer systems Data and the information integrity stored in them © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Scheduling and Resource Management ◼ Key responsibility of an OS is managing Fairness resources Efficiency ◼ Resource allocation policies must Differential consider: responsiveness © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Different Architectural Approaches ◼ Demands on operating systems require new ways of organizing the OS Different approaches and design elements have been tried: Microkernel architecture Multithreading Symmetric multiprocessing Distributed operating systems Object-oriented design © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Microkernel Architecture ◼ Assigns only a few essential functions to the kernel: Address Interprocess Basic space communication scheduling management (IPC) ◼ The approach: Well suited to a Simplifies Provides distributed implementation flexibility environment © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Multithreading Thread Process ◼ Technique in which a process, executing an Dispatchable unit of work A collection of one or more threads and associated application, is system resources divided into threads that can By breaking a single run concurrently application into multiple Includes a processor context threads, a programmer has and its own data area for a greater control over the stack modularity of the application and the timing of application-related events Executes sequentially and is interruptible © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Symmetric Multiprocessing (SMP) ◼ Term that refers to a computer hardware architecture and also to the OS behavior that exploits that architecture ◼ The OS of an SMP schedules processes or threads across all of the processors ◼ The OS must provide tools and functions to exploit the parallelism in an SMP system ◼ Multithreading and SMP are often discussed together, but the two are independent facilities ◼ An attractive feature of an SMP is that the existence of multiple processors is transparent to the user © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  SMP Advantages More than one process can be Performance running simultaneously, each on a different processor Failure of a single process does not Availability halt the system Incremental Performance of a system can be enhanced by adding an Growth additional processor Vendors can offer a range of products Scaling based on the number of processors configured in the system © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Time Process 1 Process 2 Process 3 (a) I nterleaving (multiprogramming, one processor) Process 1 Process 2 Process 3 (b) I nterleaving and overlapping (multiprocessing; two processors) Blocked Running Figure 2.12 M ultiprogramming and M ultiprocessing © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  OS Design Distributed Operating Object-Oriented System Design ◼ Provides the illusion of a single ◼ Lends discipline to the process of adding modular extensions to main memory space and a single a small kernel secondary memory space plus other unified access facilities, such ◼ Enables programmers to as a distributed file system customize an operating system without disrupting system ◼ State of the art for distributed integrity operating systems lags that of uniprocessor and SMP operating ◼ Also eases the development of systems distributed tools and full-blown distributed operating systems © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Fault Tolerance ◼ Refers to the ability of a system or component to continue normal operation despite the presence of hardware or software faults ◼ Typically involves some degree of redundancy ◼ Intended to increase the reliability of a system ◼ Typically comes with a cost in financial terms or performance ◼ The extent adoption of fault tolerance measures must be determined by how critical the resource is © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Fundamental Concepts ◼ The basic measures are: ◼ Reliability ◼ R(t) ◼ Defined as the probability of its correct operation up to time t given that the system was operating correctly at time t=o ◼ Mean time to failure (MTTF) ◼ Mean time to repair (MTTR) is the average time it takes to repair or replace a faulty element ◼ Availability ◼ Defined as the fraction of time the system is available to service users’ requests © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Class Availability Annual Downtime Continuous 1.0 0 Fault Tolerant 0.99999 5 minutes Fault Resilient 0.9999 53 minutes High Availability 0.999 8.3 hours Normal Availability 0.99 - 0.995 44-87 hours Table 2.4 Availability Classes © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Faults ◼ Are defined by the IEEE Standards Dictionary as an erroneous hardware or software state resulting from: ◼ Component failure ◼ Operator error ◼ Physical interference from the environment ◼ Design error ◼ Program error ◼ Data structure error ◼ The standard also states that a fault manifests itself as: ◼ A defect in a hardware device or component ◼ An incorrect step, process, or data definition in a computer program © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Fault Categories ◼ Permanent A fault that, after it occurs, is always present The fault persists until the faulty component is replaced or repaired ◼ Temporary A fault that is not present all the time for all operating conditions Can be classified as ◼ Transient – a fault that occurs only once ◼ Intermittent – a fault that occurs at multiple, unpredictable times © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Operating System Mechanisms ◼ A number of techniques can be incorporated into OS software to support fault tolerance: ◼ Process isolation ◼ Concurrency controls ◼ Virtual machines ◼ Checkpoints and rollbacks © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Traditional UNIX Systems ◼ Developed at Bell Labs and became operational on a PDP-7 in 1970 ◼ The first notable milestone was porting the UNIX system from the PDP-7 to the PDP-11 ◼ First showed that UNIX would be an OS for all computers ◼ Next milestone was rewriting UNIX in the programming language C ◼ Demonstrated the advantages of using a high-level language for system code ◼ Was described in a technical journal for the first time in 1974 ◼ First widely available version outside Bell Labs was Version 6 in 1976 ◼ Version 7, released in 1978, is the ancestor of most modern UNIX systems ◼ Most important of the non-AT&T systems was UNIX BSD (Berkeley Software Distribution), running first on PDP and then on VAX computers © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  coff a.out elf exec switch NFS file mappings FFS virtual device memory vnode/vfs mappings framework interface s5fs anonymous RFS mappings Common Facilities disk driver time-sharing block processes device scheduler switch framework tape driver system processes STREAM S network tty driver driver FigureFigure 2.17 2.16 Modern M odern UNI UNIX Kernel X Kernel [VAHA96] © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  LINUX Overview ◼ Started out as a UNIX variant for the IBM PC ◼ Linus Torvalds, a Finnish student of computer science, wrote the initial version ◼ Linux was first posted on the Internet in 1991 ◼ Today it is a full-featured UNIX system that runs on virtually all platforms ◼ Is free and the source code is available ◼ Key to the success of Linux has been the availability of free software packages under the auspices of the Free Software Foundation (FSF) ◼ Highly modular and easily configured © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Android Operating System ◼ A Linux-based system originally ◼ Most recent version is Android designed for mobile phones 7.0 (Nougat) ◼ The most popular mobile OS ◼ Android has an active community of developers and ◼ Development was done by enthusiasts who use the Android Android Inc., which was bought Open Source Project (AOSP) by Google in 2005 source code to develop and distribute their own modified ◼ 1st commercial version (Android versions of the operating system 1.0) was released in 2008 ◼ The open-source nature of Android has been the key to its success © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Application Framework ◼ Provides high-level building blocks accessible through standardized API’s that programmers use to create new apps ◼ Architecture is designed to simplify the reuse of components ◼ Key components: Activity Window Package Telephony Manager Manager Manager Manager Java abstraction of Manages lifecycle of the underlying applications Surface Manager Allows interaction Installs and removes with phone, SMS, applications Responsible for Allows applications and MMS services starting, stopping, to declare their client and resuming the area and use features various applications like the status bar © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Application Framework (cont.) Content Resource View Location Notification XMPP Providers Manager System Manager Manager These Allows functions developers to encapsulate Manages tap into Provides the Provides application application location- Manages user interface standardized data that resources, based events, such (UI) messaging need to be such as services, as arriving primitives as functions shared localized whether by messages and well as UI between between strings and GPS, cell appointments Events applications applications bitmaps tower IDs, or such as local Wi-Fi contacts databases © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  System Libraries ◼ Collection of useful system functions written in C or C++ and used by various components of the Android system ◼ Called from the application framework and applications through a Java interface ◼ Exposed to developers through the Android application framework ◼ Some of the key system libraries include: ◼ Surface Manager ◼ OpenGL ◼ Media Framework ◼ SQL Database ◼ Browser Engine ◼ Bionic LibC © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  ◼ Most Android software is mapped into a bytecode format which is then transformed into native instructions on the device itself Earlier releases of Android used a Android ◼ scheme known as Dalvik, however Dalvik has a number of limitations in terms of scaling up to larger Runtime memories and multicore architectures ◼ More recent releases of Android rely on a scheme known as Android runtime (ART) ◼ ART is fully compatible with Dalvik’s existing bytecode format so application developers do not need to change their coding to be executable under ART ◼ Each Android application runs in its own process, with its own instance of the Dalvik VM © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Advantages and Disadvantages of Using ART Advantages Disadvantages ◼ Reduces startup time of ◼ Because the conversion from applications as native code is bytecode to native code is done at directly executed install time, application installation takes more time ◼ Improves battery life because processor usage for JIT is avoided ◼ On the first fresh boot or first boot after factory reset, all applications ◼ Lesser RAM footprint is required installed on a device are compiled for the application to run as there to native code using dex2opt, is no storage required for JIT therefore the first boot can take cache significantly longer to reach Home Screen compared to Dalvik ◼ There are a number of Garbage Collection optimizations and ◼ The native code thus generated is debug enhancements that went stored on internal storage that into ART requires a significant amount of additional internal storage space © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Applications and Framework Binder I PC Android System Services M edia Server System Server Power AudioFlinger M ediaPlayer Window M anager Service M anager Service Camera Activity Other M edia Service M anager Other Services Services Android Runtime/Dalvik Hardware Abstraction Layer (HAL) Camera HAL Audio HAL Graphics HAL Other HALs Linux Kernel Audio Driver Camera Driver Display Drivers (ALSA, OSS, etc) Other Drivers Figure 2.22 Android System Architecture © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Activities An activity is a single visual user interface component, including things such as menu selections, icons, and checkboxes Every screen in an application is an extension of the Activity class Activities use Views to form graphical user interfaces that display information and respond to user actions © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Power Management Alarms Wakelocks ◼ Implemented in the Linux kernel ◼ Prevents an Android system from and is visible to the app developer entering into sleep mode through the AlarmManager in the RunTime core libraries ◼ These locks are requested through the API whenever an application ◼ Is implemented in the kernel so requires one of the managed that an alarm can trigger even if peripherals to remain powered on the system is in sleep mode ◼ This allows the system to go ◼ An application can hold one of into sleep mode, saving the following wakelocks: power, even though there is ◼ Full_Wake_Lock a process that requires a ◼ Partial_Wake_Lock wake up ◼ Screen_Dim_Wake_Lock ◼ Screen_Bright_Wake_Lock © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.  Summary ◼ OS design considerations for ◼ Operating system objectives and multiprocessor and multicore functions ◼ Microsoft Windows overview ◼ User/computer interface ◼ Traditional Unix systems ◼ Resource manager ◼ History/description ◼ Evolution of operating systems ◼ Modern Unix systems ◼ Serial processing ◼ System V Release 4 (SVR4) ◼ Simple/multiprogrammed/time- ◼ BSD sharing batch systems ◼ Solaris 10 ◼ Major achievements ◼ Linux ◼ Developments leading to modern ◼ History operating systems ◼ Modular structure ◼ Fault tolerance ◼ Kernel components ◼ Fundamental concepts ◼ Android ◼ Faults ◼ Software/system architecture ◼ OS mechanisms ◼ Activities ◼ Power management © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.