CPS221 Lecture: Operating System History last revised 6/23/10. Objectives

Transcription

1 Objectives CPS221 Lecture: Operating System History last revised 6/23/10 1. To survey the history of operating systems 2. To survey the modern operating system landscape 3. To introduce key notions: multiprogramming, preemption Materials: 1. Projectable pictures of IBM 1620 (2 versions) 2. Projectable of steps compiling and running a FORTRAN program on a Projectable of stacked job batch monitor memory and input tape I. Introduction A. Today's operating systems are among the largest, most complex, most versatile pieces of software on the market. To a large extent, the operating system carries the burden of ensuring efficient, reliable, secure availability of the computer system to its users. However, this was not always the case. Operating systems have undergone a process of evolution from the earliest days of computing - when there were essentially no operating systems - through fairly small and simple one-userat-a-time systems, through increasingly complex multi-user systems, to their present role. B. We want to spend some time surveying some of the highlights of this process of development - for two reasons: 1. One way to get a handle on the complexity of modern operating systems is to see how they have developed one layer at a time. If we picture an operating system as an onion, then our historical survey will help us to examine the construction of the onion one layer at a time. 2. The proliferation of small, high powered computers has brought us fullcircle in many areas of Computer Science, including operating systems. For example, a modern cell phone has far more computational power than mainframe computers of a few decades ago. A cell phone operating system capability (multitasking) has become an issue in competitive battles between Apple s IPhone and various cell phones running Google s Android. C. As an overview, we can note several key stages in the evolution of modern operating systems, originally driven by a desire to make the most 1

2 efficient use of an expensive resource. (Early computers cost in the 100 s of 1000 s of $ or more, though that s no longer an issue!) 1. One user systems on a bare machine 2. Stacked job batch processing systems. 3. Multiprogrammed batch processing systems. 4. Timeshared systems. 5. The development of personal computers D. We will also want to take a quick look at the modern operating system landscape, which reflects this history, as we shall see. II. One User Systems on a Bare Machine A. In the earliest days of computing, there were no operating systems per se. This meant that the user ran on a bare machine. Understanding what this entailed can help us understand the interface between a modern operating system and the underlying machine. B. An example: the IBM 1620 of the early 1960's PROJECT Pictures (two) 1. The first machine I ever used (as a high school student in a summer program at IIT). 2. A particularly easy bare machine to understand. 3. Some characteristics: a) Three IO devices on the machine I used: (1) console device: modified IBM Selectric typewriter (In, out). (2) punched card reader. (3) punched card punch. b) Programs were normally prepared using offline keypunches. Printed output could be obtained by punching the output, then running it through an offline printer (though many 1620s had online printers). 2

3 c) Relatively powerful IO instructions in hardware repertoire: (1) One instruction to read a single card into adjacent memory locations (2) One instruction to punch a card from adjacent memory locations. (3) One instruction to read a line from typewriter into adjacent memory locations. (4) One instruction to type a numeric field to the typewriter (5) One instruction to type a string of adjacent characters. d) Initial load provision: a button on the card reader could cause a single card to be read into memory locations 0-79, with the CPU starting to execute the instruction at location 0. A single card could contain six machine instructions. These, in turn, would serve to load the rest of the loader and some program. 4. Process for compiling/running a program written in a higher level language like FORTRAN: PROJECT Steps a) Place the FORTRAN compiler - pass one - card deck in the reader, followed by the source program.. The compiler included its own loader, so just press initial program load. b) FORTRAN pass 1 would then punch an intermediate file to the card punch. c) Place the FORTRAN compiler - pass two - card deck in the reader, followed by this intermediate program. Again, since the compiler included its own loader, so just press initial program load d) Pass two would produce an object deck on the punch. e) Place the FORTRAN library card deck in the reader, followed by the object deck. Since the library included a loader for itself and the object program, and press initial program load to run the program. 3

4 f) Of course, further results would depend on the program being run. If, as was often the case, a large volume of output was to be produced, the program would punch an output deck which could then be printed offline.. g) If there were errors in the program, one could interact directly with it from the console by halting the machine and using the console to examine and/or modify individual memory locations. 5. The particular machine I used was made available to users in two ways a) Daytime - an operator on duty would accept program decks, run them, and return the output some hours later. He could economize on time by batching compilations in FORTRAN or other languages e.g. he could run several source programs through pass one, then run the resulting intermediate decks through pass two - thus saving the problem of having to reload the compiler for each source program. b) Nighttime - one could reserve a block of time for dedicated computer use, or a group of users (e.g. the people in the high-school program I was in) could be given the machine to share among themselves in whatever manner was worked out. C. This kind of environment had some serious problems: 1. Knowledge of machine language was almost mandatory - if not for programming, then for debugging. 2. Hardware utilization was very inefficient. Much of the time the CPU was idle waiting for the relatively slow reader or punch, or for the even slower human to load the reader or punch. 3. Card decks, such as the FORTRAN compiler, were vulnerable to wear and tear. And woe to the person who dropped the compiler deck! III. Early stacked job batch systems A. I noted that, on the particular machine I described, it was the practice to have all daytime jobs run by an operator, rather than the programmer. This improved the degree of utilization of the machine, for several reasons: 1. The operator, being experienced, could load the necessary decks more quickly. 4

5 2. The operator could batch similar jobs to avoid frequently reloading system programs such as the compiler. 3. Since the user could not interact with a running program, the system resources were never tied up waiting for a user to finish thinking and type a line of input. B. Of course, the latter advantage is also one of the chief disadvantage of such a system. A consequence of the move to stacked job systems was that programmers lost the ability to interact with programs - making debugging much harder. If the program failed, the operator was instructed to produce a dump of memory for the programmer to analyze. (Finding an error by poring over pages of binary contents of memory is not a pleasant task!) C. The 1620 was a relatively cheap machine. 1. On more expensive machines, 24-hour operation by a special operator was the norm. 2. Further, since throughput would be severely limited by the speed of card input and output, larger machines often used magnetic tape (much faster) - often with some provision to read cards onto tape offline, and to print output from tape offline. (Either special card-to-tape units or possibly a small dedicated computer controlling a number of readers, punches, printers and tape drives.) (Intermediate compiler files, of course, never got onto cards at all - they were created on tape and then read from tape.) 3. In the 1960's, drum and disk storage became common on larger machines. Typically, the disk was used to store commonly-used programs such as compilers, so that these did not have to be read in from cards or tape whenever needed. (Mounting the correct tape would be very time consuming.) D. With commonly used programs stored in secondary storage on the machine (disk, drum, or tape) and a series of individual user jobs one behind another on a reel of magnetic tape, it became necessary to put more of the burden for system control on the machine, since the operator could no longer see the physical division points between user jobs once they were read onto tape. 1. Each user job would include a series of control cards, identifying the user and the task he wished performed: 5

6 a) e.g. a $FORTRAN card might specify a FORTRAN compilation, which would require that the compiler be read from disk. The source program would immediately follow the $FORTRAN card and would be read by the compiler as soon as it was loaded. b) Again, $LOAD might call for the resultant object program to be read into memory; c) $RUN might call for executing it, with the input data being placed immediately behind the $RUN card. 2. The program that managed the system was known as the monitor. It would be loaded when the system was powered up, and would remain resident in a designated region of memory at all times. This kind of monitor is commonly called a stacked job monitor - because jobs are processed as if they were physically stacked one behind the other in a card reader (though in fact the stacking was on tape or disk.) Primary Memory Monitor (Permanently Resident) Program currently being run on behalf of a user. Secondary Storage System programs (compilers, libraries, etc.) Layout of input tape $JOB user id $FORTRAN FORTRAN source program $LOAD $RUN data for program $EOJ $JOB user id $LOAD application on disk $RUN data for program $EOJ $JOB user id... PROJECT. Walk through diagram; then project steps in executing jobs 3. The earliest stacked job monitors were developed by users in the mid 1950's. By the late 1950's, it was the norm for manufacturers to furnish an operating system with large machines. Smaller machines e.g satellites, 1620) ran bare with an IO library. 6

7 4. Eventually, the command language recognized by the monitor grew into a very sophisticated language known as JCL (job-control language) that is still used on mainframe computers. This is, in effect, the user interface of the operating system. E. The advent of stacked job monitors created some interesting problems that called for additional hardware features. 1. Since a series of jobs would follow one another on the tape, it was vital that one job not be able to do anything that would interfere with the other jobs on the tape: a) If one job - through error or maliciousness - damaged the monitor, then the remaining jobs on the tape could be processed incorrectly or not at all. b) If one job contained an error it might not stop reading with its own data, but might begin reading the control cards, program, and data for the next job. Thus, when the monitor regained control it would not see some or all of the next job. c) A program might go into an infinite loop, blocking all subsequent jobs. 2. Dealing with these problems called for hardware features to be added to the system. The key feature was the addition of the concept of processor mode, as we have previously discussed. (Although the two modes are today conventionally called kernel and user, the term monitor mode was often used at this time to mean what we now mean by kernel mode ) a) The monitor region of memory was made off limits when the processor was in user mode. A simple way to do this for a stacked job monitor was with a fence register - addresses below the fence are accessible (or at least alterable) only when in monitor mode. The fence would be set so that the monitor could not be touched by a program running in user mode. This solved the first problem. b) To solve the second problem 2, it was required that all input and output be done by the monitor, rather than by user programs, by making IO instructions privileged - i.e. executable only in monitor mode. (An attempt to execute one of these in user mode would be treated as a fatal error terminating the program.) 7

8 This means that a user program had to transfer control to the monitor whenever it wants IO done. The monitor could then take steps to be sure that the IO operation is legitimate - e.g. that the user is not attempting to read a control card belonging to the next job (or worse yet to write to the job input tape!) c) A timer was used to solve the third problem. The monitor would set it to a suitable interval (often specified by the user on the first control card in the job) before passing control to the user program. If the timer ran out before the user program is finished, it interrupted the CPU, causing transfer to a timer interrupt handler routine which is part of the monitor. This routine would then terminate the offending job with a suitable error dump and then advance the input tape to the next job. (Of course, the instruction that sets the timer must be privileged!) Note: In practice, especially on current machines, timers are often implemented by a device that interrupts the CPU at regular intervals - with a counter in the monitor memory that is decremented by 1 on each interrupt. Timeout is deemed to occur when the counter reaches 0. F. The above marked the introduction of what has become a key concept in operating system design: protection. 1. In a system that is shared among multiple users, it is necessary to protect each user from accidental or intentional interference by others. 2. The operating system (which has unlimited access to the system) must be protected from damage by users. This is mandatory on a multiple user system, but even desireable on a one user system a) Example: Gordon's old PDP-8: during one programming project we had a rash of accidental erasures of part of the disk containing the operating system due to a bug that many students seemed to share. b) Example: Software crashes due to errors in one piece of software were quite common on early PC operating systems such as earlier versions of Windows or pre OS-X Macintoshes. 3. Protection typically requires some hardware facilities - e.g. a two mode CPU with privileged instructions for IO and certain other operations, and some form of memory partitioning. There is thus a strong interaction between operating systems and computer architecture. 8

9 4. Note that protection is not the same thing as security - though the two are closely related: a) Protection is concerned with mechanisms that help to ensure correct operation even in the face of erroneous or malicious code. b) Security is concerned with taking measures to ensure that the protection mechanisms are not bypassed (e.g. to obtain access to information one is not authorized to see, or to alter information illegitimately, or just to crash the system.) IV. Multiprogramming A. The stacked job batch system we have described achieved an improvement in system efficiency by eliminating the time required for the human operator to load each job on the system. In its simplest form, though it left a lot to be desired in terms of overall utilization of the system resources. 1. Consider a typical job that looks like this: while not eof read a card do some computation on the data on it print a line of output 2. If we traced the behavior of this program over time, what we would see the following pattern: Reading _1 2 3_ Computing _1 2 3_ Printing _1 2 3_ a) If all three phases take equal time (unusual but possible), then each component of the system (reader, CPU, printer) is busy 33% of the time and idle 66%. b) Actually, for many data processing tasks IO takes much more time than computation (since IO devices are typically electro-mechanical), so that the CPU utilization may be under 10%. c) Given the high cost of the CPU ($100's of 1000's at that time), this was very undesirable. d) Use of faster IO devices (e.g. magnetic tape) helped to alleviate this problem In a simple batch system, cards could be read onto tape offline, with the CPU reading card images from the tape and producing line images on a second tape which is later printed 9

10 offline. This would reduces but not eliminate the CPU time wastage - and added the additional complication of tape handling which can increase turnaround, since an entire tape has to be filled offline before any jobs on it can actually be processed. B. Further improvements took advantage of an IO strategy known as Direct Memory Access (DMA) - whereby an IO controller could carry out an operation concurrently with other computation done by the CPU. If there is a small amount of memory beyond the absolute minimum needed to run a job, we can allocate two buffers each for input and output and proceed as follows read a card image into in buffer 1 process in buffer 1 to out buffer 1, while at the same time reading a card image into in buffer 2 process in buffer 2 to out buffer 2, while at the same time: reading a card image into in buffer 1 and printing a line from out buffer 1 process in buffer 1 to out buffer 1, while at the same time reading a card into in buffer 2 and printing a line from in buffer 2 1. Our utilization now looks like this, assuming (unrealistically) that reading, computing, and writing take equal time: Reading _ _... Computing _ _... Printing _ _... (Except during startup and wrapup, all devices used near 100% capacity) 2. If we make the more realistic assumption that reading and printing take comparable time, but computing takes much less, we get something like: Reading Computing _ _... Printing (IO utilization near 100%; CPU utiliztion much less) 3. On the other hand, some jobs require much more computation time than IO time (e.g. those involving some form of "number crunching".) For these, we might have a pattern like: 10

11 Reading _ _... Computing Printing _ _... (CPU utilization near 100%; IO usage much less) 4. If it was typical for a particular computer installation to run only IO bound jobs, then we would have to live with a low CPU utilization, since the CPU can only be busy when it has data to work with. Again, if compute bound jobs are typical, we would have to live with low IO utilization, since the IO devices can only be busy when the CPU has done its work on the data. But if we have a mixture of types of job, then we would like to see near 100% utilization of all resources. However, in a typical stacked job scheme, we would get a burst of heavy IO activity/light CPU activity, followed by a burst of light IO activity/heavy CPU activity - leading to overall utilization below 50% for all resources. Solution to this problem requires a further development in operating systems. C. Multiprogramming emerged in the early 1960's 1. The preceeding development has assumed that, at any one time, the computer system is processing exactly one user job. Incoming jobs are stacked, and the system does not start working on one until it has completed its predecessor, with the result that some components of the system are not fully utilized (often the most expensive of all: the CPU) 2. For this reason, systems moved to multiprogramming multiple processes, in the hopes that CPU bound phases of one job will overlap IO bound phases of others. a) Of course, to support multiprogramming, it also became necessary to provide additional memory to accomodate the additional processes. b) Further, the protection problem became more complex, since it is now necessary not only to protect the monitor from accidental (or deliberate) alteration by a user job, but also to protect user jobs from one another. D. A key concept in multiprogrammed systems is the notions of priority and preemption to handle the commonly-occurring case where multiple jobs are able to use the CPU at the same time. 11

12 1. Priority would typically be given to a job exhibiting IO-bound behavior, rather than one exhibiting CPU-bound behavior, and when an IO operation was completed the job that was waiting for it might be allowed to preempt a CPU-bound job. Why? ASK 2. In some cases, external priorities might also be used, set on the basis of the relative importance of different jobs. V. Timesharing A. In our survey of operating system history, we saw that the earliest systems provided a hands-on environment in which the programmer was able to interact with the program as it ran. Demands for efficient utilization of expensive hardware soon led to this capability being abandoned in favor of batch systems of various sorts. B. Interaction of a sort was restored fairly quickly for certain kinds of applications, such as airline reservations. One of the most important early large-scale software systems was the American Airlines SABRE system, which connected agents all over the country to a common data base of reservations. Inquiries keyed in on a terminal would receive a quick response. The underlying software, however, was not multiprogrammed, but rather a single package of programs that divided its attention among many terminals. 1. Such a system is called a transaction processing system, and is still common today in such areas as airline reservations, bank ATM's etc. 2. A similar idea exists with various server programs (web, , etc ) in which a single program may respond to requests coming from many different users. C. Shortly after multiprogramming appeared, efforts were begun to fully restore the interactive dimension to general-purpose computing through the use of timesharing. 1. A timeshared system restores interactivity by having the jobs being multiprogrammed do IO not from a (virtual) card reader and to a (virtual) printer but rather from and to a terminal with a live user in front of it. 2. The monitor used in a stacked job system is effectively replaced by a command interpreter that now served as the user interface by allowing the user to enter commands interactively. 12

13 3. The timer is now used to divide the available CPU time between different users. a) In the approach known as round robin, the system maintains a ready list of users needing to use the CPU. b) When a user job gets to the front of the line, it is given a quantum of CPU time. (1) If the computation being done results in an IO request, the job yields the CPU until the IO operation has been completed, and then gets back in line. (2) If the job continues to need the CPU at the end of this time (the program has not yet initiated an IO operation), it is placed at the back of the line and another job is given the CPU. (This is known as timer preemption). (3) Thus, each user gets slices of the available CPU time. If the CPU is fast enough, this can give the appearance of the user having access to a dedicated (but not as fast) CPU. c) A priority scheme could also be used to modify the round robin behavior. (1) External priority, as discussed in the context of batch systems. (2) Jobs exhibiting IO-bound behavior might be given priority over jobs exhibiting compute-bound behavior. (3) It was also common to give a bump in priority to a job that had been waiting for user input when that input finally arrived. Why? ASK (4) Priority might be combined with some sort of aging scheme, to prevent indefinite postponement. (As a job waited, its priority would slowly be increased) 4. Timeshared systems are more difficult to implement than multiprogrammed batch systems or transaction processing systems, for several reasons: 13

14 a) The typical interactive process has much more IO wait time than a batch process. With a batch process, all of the input data is available when the process starts; while an interactive process has to wait for the user to type each line - often with some thinking time in between lines. Therefore, to keep the CPU busy it is typically necessary to multiprogram more jobs so that hopefully at least one is able to use the CPU. b) In a batch system, it is permissible for a particular job to go for a long time without service from the system, so long as it completes within a reasonable time. In an interactive system, it is essential that the user receive fairly quick response from the system whenever he does get around to issuing a command. c) In contrast to a transaction processing system, where a common program is shared among all users, with each user having a very small area of private memory (perhaps enough to hold a few lines of text), a general-purpose timesharing system must provide each user with enough memory to hold a complete program and related data. This was a serious problem in the days of high-cost memory. D. Today, of course, the need to make efficient use of an expensive resource (the CPU) is no longer an issue, and for this reason many of the timeshared systems of the 1980 s and 1990 s are now only of historical interest. However, one system that began as a timeshared system has played a very influential role: Unix. 1. Unix was originally developed at Bell Telephone Labs (now part of AT&T) in An important variant was developed at Berkeley starting in Today, the following systems are all descendants of one or the other of these: a) Darwin - the core of MacIntosh OSX b) Solaris - the system on which Java was first developed (Sun Microsystems - now part of Oracle) c) HP/UX (Hewlett-Packard) d) AIX (IBM) 14

15 4. Though Linux is technically a separate system, many of its core ideas come from Unix. Due to trademark issues, one cannot refer to it as Unix, but for all intents and purposes that is really what it is! 5. Ideas from Unix also influenced MS/DOS, which became the foundation on which Windows was first developed. 6. Unix has also played a central role in Operating Systems research in CS. VI. Personal Computers A. Operating systems evolved in the context of fairly expensive large computers, with efficient utilization of resources being a high priority. B. The personal computer has its roots in hobbyist systems developed in the 1970 s, followed by the IBM PC (1981) and Macintosh (1984). Because PC s are based on inexpensive technology, efficient utilization is not a key issue - indeed, the average PC spends most of its time sitting idle. C. Early PCs ran a variety of one-user operating systems, but by the late 1980 s two had become widespread: 1. MS/DOS (Micrososft) running on Intel x86 platforms 2. Macintosh OS running on Macintoshes which at that time used either the Motrorola or Power PC processors. 3. Both systems resembled a cross between one user and stacked job batch systems, with a small IO library in memory without any protection and an interactive command interpreter reading commands typed by the user (DOS) or a GUI (Macintosh) in place of input coming from a card reader or tape. 15

16 MS/DOS BIOS + BDOS Early Macintosh BIOS + Toolbox Command Interpreter Program currently being run on behalf of a user. Finder Program currently being run on behalf of a user. (Actually, there is also an interesting relic of the batch heritage in the existence of.bat files on Windows systems) 4. In contrast with stacked job batch systems, however, neither system had any provisions for protecting the memory belonging to the operating system or command interpreter from being damanged by an error in the program being run. D. In the late 1980 s MS/DOS morphed into Windows, using a GUI instead of a command interpreter as the primary mechanism for user interaction, and both began to support multiprogramming. 1. Of course, the motivation for multiprogramming in PC s is very different from efficient uses of expensive resources that was the original motivation. Reliance on multiprogramming has become part of how we work. For example, as I am writing this lecture on a word-processor, I am also running an program and periodically use my web browser to check various facts. 2. Early versions of Windows and multiprogrammed versions of Mac OS did not provide for memory protection, and used cooperative rather than preemptive multitasking. (In cooperative multitasking, a job is not forced to yield the CPU, which allows a CPU-intensive program or one with an infinite loop to hog the system.) a) These capabilities were added to later versions of Windows. b) In 2001, Apple replaced its earlier Classic MacOS with a totally new OS (OSX) whose kernel (Darwin) was a descendant of 16

17 Berkeley Unix) and therefore supports both memory protection and preemptive multitasking. E. Linux emerged as a third alternative in the 1990 s. 1. With its Unix heritage, Linux has always incorporated many of the ideas developed in conjunction with mutiprogramming and timeshared systems (such as memory protection and pre-emptive multitasking). 2. Linux systems are often accessed using a text-based command interpreter (the shell). However, current Linux systems incorporate a number of GUI features. a) A windowing system known as XWindows. b) Two different GUI desktops: Gnome and KDE VII. Real-Time Systems A. All of the systems we have been looking at so far have been designed for general-purpose computing. There is, however, another broad category of computing use called real-time systems. 1. A real-time system is interacting with hardware devices in real time, and is therefore characterized by inflexible time constraints: if the system cannot respond to external events within some time limit, bad things can happen. 2. One major kind of real-time systems is a system that is used to collect data from some sort of instrument (e.g. in a laboratory). If such a system cannot handle the data as fast as it is being produced, information may be lost. 3. Another major kind of real-time systems is an embedded system that is used to control a physical system. a) Examples (1) Cell phones and similar smart devices (2) Entertainment devices like TV set-top boxes, DVD players, game consoles... (3) Devices that control devices like an ATM. 17

18 (4) Automobile systems that control fuel injection, anti-lock brakes... (5) Systems used to control airplanes, spacecraft, missiles, etc. (6) Systems used in the power grid to control power plants and the dsitribution of electricity... b) If such an embedded system cannot respond quickly enough to events in the device(s) it is controlling, negative consequences may range from user dissatisfaction to an automobile, airplane, spacecraft, or missile crash or a power blackout. B. Real-Time Systems can be classified as soft real-time or hard real-time. 1. In a soft real-time system, while failure to meet the time constraints is undesirable, it is not catastrophic. Soft real-time systems may utilize appropriate software running on a general-purpose platform (which may be dedicated to this one application or may be running other applications as well), or they may use a special operating system as on a hard real-tiime system. 2. In a hard real-time system, failure to meet the time constraints is unacceptable. Hard real-time systems use special-purpose real-time operating systems. a) Often, this is a stripped-down version of a general purpose operating system (e.g. a real-time version of Linux). b) There are also special systems designed from the ground up as real time systems - e.g. Windows CE, iphone OS, Android... 18

19 VIII. Today s OS Landscape A. When one uses the word operating system today, what often comes to mind first is PC operating systems (Windows, MacOS, Linux), of course. B. Network servers are also ubiquitous. These may run special server or enterprise versions of Windows, MacOS, or Linux. C. Also, mainframe ( big iron ) systems are still used extensively by larger corporations. (Think for a moment about the information processng needs of a bank or an insurance company, or the census, for example). IBM dominates this market, with zos being its dominant system. These may run a transaction processing system known as CICS (Customer Information Control System) that is extensively used by people like bank tellers. D. Real-time operating systems are found in many contexts other than computer systems. E. Finally, in a networked world many services that were once provided by the operating system on a single machine are instead provided over a network. 1. Network file systems For example, the disks on the workstations in M107 hold only the operating system and application programs - they do not hold user files. Instead, they use a network file system, with user files stored (transparently) on a server machine (files.cs.gordon.edu). You can use any workstation and you will see your same home directory. 2. Client-server systems. For example, nas1 and files.cs.gordon.edu hold volumes which you can explicitly mount on any machine on the campus network, at which point you can access the same set of files from wherever you are. Services such as google docs or Apple s idisk make a similar facility available world wide. 19

20 IX. Summary: Key Concepts A. In this survey of the history of operating, we saw the roots of several key ideas that play a central role in modern operating systems. B. Protection relying on two processor modes 1. The CPU incorporates a notion of processor mode: kernel or user (which can be represented by a single bit) 2. When the CPU is in kernel mode, all operations are legal, and all of memory is accessible 3. When it is in user mode, some operations are not allowed: e.g. those tha perform IO, and access to memory is limited to certain regions. 4. A trend in operating system design is to minimize the amount of code that needs to run in kernel mode - i.e. an operating system may contain both user and kernel mode code. The reason for this is that an error in user mode code only affects the program executing it, while a kernel mode error can crash the whole system. C. Multiprogramming 1. This was originally motivated by a desire to make efficient use of expensive resources - which is, of course, not really an issue today. 2. It entered the world of Personal Computers in the 1990 s as a vehicle for improved usefulness. 3. A current issue is a competive battle over support for multiprogramming on smart phones between iphone OS and Android. 4. Multiprogramming requires mechanisms in the operating system to protect programs from interfering with one another. D. The notions of preemption and priority. 1. IO preemption - An IO bound process is often allowed to preempt a CPU bound one, in the expectation that it will only need to compute briefly before requesting another IO operation. This may be formalized in a notion of process priority - where a higher priority process will get the CPU ahead of a lower priority one, and where processes that exhibit IO bound behavior are given highr priority that those that appear to be CPU bound. 20

21 2. Timer preemption - originally an all or nothing thing to prevent a job in a stacked job system from hogging the system, but later used to implement time-slicing in a timeshared system and for preemptive multitasking on personal computers. E. The provision of various sorts of user interface whereby the user can specify programs to run. 1. Job Control language in batch systems (or.bat files on Windows) 2. A command line interpreter such as the shell in Unix-like systems (including MacOS) or the command line in Windows systems 3. A graphical interface such as the MacIntosh Finder, Windows Explorer, of Gnome or KDE on Linux. 21