Operating System

Chapter 1

Type of operating system

Batch System

Stacked job batch systems (mid 1950s – mid 1960s)

A batch system is one in which jobs are bundled together with the instructions necessary to allow them to be processed without intervention.

The basic physical layout of the memory of a batch job computer is shown below:

The monitor is system software that is responsible for interpreting and carrying out the instructions in the batch jobs. When the monitor starts a job, the entire computer is dedicated to the job, which then controls the computer until it finishes.

A sample of several batch jobs might look like this:

Often magnetic tapes and drums are used to store data and compiled programs, temporarily or permanent.

Advantages of batch systems

Move much of the work of the operator to the computer
Increased performance since it was possible for job to start as soon as the previous job finished

Disadvantages

Turn-around time can be large from user standpoint
More difficult to debug program

Due to lack of protection scheme, one batch job can affect pending jobs (read too many cards, etc)

A job could corrupt the monitor, thus affecting pending jobs

A job could enter an infinite loop

One of the major shortcomings of early batch systems is that there's no protection scheme to prevent one job from adversely affecting other jobs.

The solution to this brought a simple protection scheme, where certain memory (e.g. where the monitor resides) were made off-limits to user programs. This prevented user programs from corrupting the monitor.

To keep user programs from reading too many (or not enough) cards, the hardware is changed to allow the computer to operate in one of two modes: one for the monitor and one for the user programs. IO can only be performed in monitor mode, so that IO requests from the user programs are passed to the monitor. In this way, the monitor can keep a job from reading past it's on $EOJ card.

To prevent an infinite loop, a timer is added to the system and the $JOB card is modified so that a maximum execution time for the job is passed to the monitor. The computer will interrupt the job and return control to the monitor when this time is exceeded.

Spooling batch system (mid 1960s – late 1970s)

One difficulty with simple batch systems is that the computer still needs to read the the deck of cards before it can begin to execute the job. This means that the CPU is idle (or nearly so) during these relatively slow operations.

Since it is faster to read from a magnetic tape than from a deck of cards, it became common for computer centers to have one or more less powerful computers in addition to there main computer. The smaller computers were used to read decks of cards onto a tape, so that the tape would contain many batch jobs. This tape was then loaded on the main computer and the jobs on the tape were executed. The output from the jobs would be written to another tape which would then be removed and loaded on a less powerful computer to produce any hardcopy or other desired output.

It was a logical extension of the timer idea described above to have a timer that would only let jobs execute for a short time before interrupting them so that the monitor could start an IO operation. Since the IO operation could proceed while the CPU was crunching on a user program, little degradation in performance was noticed.

Since the computer can now perform IO in parallel with computation, it became possible to have the computer read a deck of cards to a tape, drum or disk and to write out to a tape printer while it was computing. This process is called SPOOLing: Simultaneous Peripheral Operation OnLine.

Spooling batch systems were the first and are the simplest of the multiprogramming systems.

One advantage of spooling batch systems was that the output from jobs was available as soon as the job completed, rather than only after all jobs in the current cycle were finished.

Multiprogramming systems (1960s – present)

As machines with more and more memory became available, it was possible to extend the idea of multiprogramming (or multiprocessing) as used in spooling batch systems to create systems that would load several jobs into memory at once and cycle through them in some order, working on each one for a specified period of time.

At this point the monitor is growing to the point where it begins to resemble a modern operating system. It is responsible for:

• starting user jobs
• spooling operations
• IO for user jobs
• switching between user jobs
• ensuring proper protection while doing the above

As a simple, yet common example, consider a machine that can run two jobs at once. Further, suppose that one job is IO intensive and that the other is CPU intensive. One way for the monitor to allocate CPU time between these jobs would be to divide time equally between them. However, the CPU would be idle much of the time the IO bound process was executing.

A good solution in this case is to allow the CPU bound process (the background job) to execute until the IO bound process (the foreground job) needs some CPU time, at which point the monitor permits it to run. Presumably it will soon need to do some IO and the monitor can return the CPU to the background job.

Timesharing systems (1970s – present)

Back in the days of the "bare" computers without any operating system to speak of, the programmer had complete access to the machine. As hardware and software was developed to create monitors, simple and spooling batch systems and finally multi-programmed systems, the separation between the user and the computer became more and more pronounced.

Users, and programmers in particular, longed to be able to "get to the machine" without having to go through the batch process. In the 1970s and especially in the 1980s this became possible two different ways.

The first involved timesharing or timeslicing. The idea of multiprogramming was extended to allow for multiple terminals to be connected to the computer, with each in-use terminal being associated with one or more jobs on the computer. The operating system is responsible for switching between the jobs, now often called processes, in such a way that favored user interaction. If the context-switches occurred quickly enough, the user had the impression that he or she had direct access to the computer.

Interactive processes are given a higher priority so that when IO is requested (e.g. a key is pressed), the associated process is quickly given control of the CPU so that it can process it. This is usually done through the use of an interrupt that causes the computer to realize that an IO event has occurred.

Multitasking

Running two or more programs concurrently is called multitasking.

Allows threads in different processes to execute concurrently. Additionally, threads in the same process can run concurrently in different processors.

Multitasking is accomplished by context switching. With context switching, a thread executes until it is interrupted by the OS or must wait for resources. When a thread is interrupted, the system saves context of the thread (its register settings etc), loads the context of another thread and executes the new thread.

Real-time

A real-time computer is one that execute programs that are guaranteed to have an upper bound on tasks that they carry out. Usually it is desired that the upper bound be very small. Examples included guided missile systems and medical monitoring equipment. The operating system on real-time computers is severely constrained by the timing requirements.

Dedicated computers are special purpose computers that are used to perform only one or more tasks. Often these are real-time computers and include applications such as the guided missile mentioned above and the computer in modern cars that controls the fuel injection system.