3.1.a The Main Features of Operating Systems
The operating system (OS) must provide and manage hardware resources as well as provide an interface between the user and the machine and between applications software and the machine. The OS must also provide other services such as data security.
Originally, if a program needed input, the program would have to contain the code to do this, similarly if output were required. This led to duplication of code so the idea of an OS was born. The OS contained the necessary input and output functions that could be called by an application. Similarly, disk input and output routines were incorporated into the OS. This led to the creation of ...view middle of the document...
Suppose two programs are stored in memory and, if one is using an input or output device (both very slow compared to the processor), it makes sense for the other program to use the processor. In fact this can be extended to more than two programs as shown in Fig. 3.1.a.1.
The OS must now manage the memory so that all three programs shown in Fig. 3.1.a.1 are kept separate as well as any data that they use. It must also schedule the jobs in the sequence that makes best use of the processor.
This is satisfactory so long as nothing goes wrong. Unfortunately things do go wrong and sometimes the normal order of operation needs to be changed. For example, a user has used up all the time allocated to his use of the processor. This change in order is instigated by interrupts. The nature of each of these interrupts is
• I/O interrupt
o Generated by an I/O device to signal a job is complete or an error has occurred. E.g. printer is out of paper or is not connected.
• Timer interrupt
o Generated by an internal clock indicating that the processor must attend to time critical activities (see scheduling later).
• Hardware error
o For example, power failure which indicates that the OS must close down as safely as possible.
• Program interrupt
o Generated due to an error in a program such as violation of memory use (trying to use part of the memory reserved by the OS for other use) or an attempt to execute an invalid instruction (such as division by zero).
If the OS is to manage interrupts, the sequence in Fig. 3.1.b.1 needs to be modified as shown in Fig. 3.1.b.2.
Is there an interrupt?
Service the interrupt
Any more instructions?
This diagram shows that, after the execution of an instruction, the OS must see if an interrupt has occurred. If one has occurred, the OS must service the interrupt if it is more important than the task already being carried out (see priorities later). This involves obeying a new set of instructions. The real problem is 'how can the OS arrange for the interrupted program to resume from exactly where it left off?'. In order to do this the contents of all the registers in the processor must be saved so that the OS can use them to service the interrupt. Chapter 3.3 explains registers that have to have their contents stored as well as explaining the fetch/execute cycle in more detail.
Another problem the OS has to deal with happens if an interrupt occurs while another interrupt is being serviced. There are several ways of dealing with this but the simplest is to place the interrupts in a queue and only allow return to the originally interrupted program when the queue is empty. Alternative systems are explained in Section 3.1.c. Taking the simplest case, the order of processing is shown in Fig.3.1.b.3.
Is there an interrupt
in the interrupt queue?