Graham R. Brookes

Basic Operating System Concepts

We shall begin our consideration of operating systems by asking the following questions: n n(1) n nWhat is an operating system? n n n n n(2) n nWhy are operating systems needed? n n n n n(3) n nDo situations exist when they are not needed? n n n n n(4) n nHow would an operating system be designed?

Time-Sharing Systems

The simple spooling system considered in chapter 3 is fairly restricted in its applications. Its mode of working, where single jobs or batches of jobs are submitted to the machine and a job is started only when the previous one has been completed, is very effective in achieving good utilisation of the computer system. However, it is not particularly convenient from the user’s point of view. The ability to interact with a program is both desirable when developing software and essential for certain types of applications, yet this facility is not available with the spooling system. Thus, a more common type of operating system is the multi-access or time-sharing system, where many users are (apparently) able to make simultaneous use of the computer.

Memory Management — Algorithms and Performance

The previous three chapters have discussed the development of the memory management systems leading to a paging system. The performance of a paging system will now be considered.

Memory Management — Segmentation

The memory management system described in chapter 8 provides an adequate set of facilities for implementing a reasonable time-sharing system. Each user process has its own virtual store which is protected from interference by other processes by the use of the base-limit register. Additionally, this mechanism protects the operating system from illegal accesses by the user programs. Many early computers relied solely on this technique for implementing a suitable multi-access system, but there are still a number of major problems outstanding for the system designer, most notably: (a) fragmentation, (b) locality of programs and (c) sharing of data structures or code, such as compilers and editors. Each of these will now be considered.

Memory Management — Basic Principles

The allocation of storage to the processes in a time-sharing system poses one of the most major problems to the designer of operating systems. If the system is supporting a large number of user processes, say N, in general it is impractical to keep all of them in memory, as on average only 1/N of the store will be in use at any given instant. Apart from the process that is currently running, some processes will be waiting for a time slice and some (usually the overwhelming majority) will be waiting for a response from the user. This latter category is the most problematic, as the typical response that can be expected from the user might be of the order of a few seconds (but might even be hours). Clearly, the system should not allow such a valuable commodity as its main storage to be underutilised to such an extent.

Job Control Systems

The aims and objectives of an operating system were considered in the opening chapters. The second part of this book has largely concentrated on the development of such systems, and we have seen some of the limitations and the need for compromise for specific requirements. However, for most computer users, there is no requirement to understand the workings of the operating system, which is treated simply as a sealed box. It is, however, necessary for the user to say how he wants his job to be run. To achieve this, the user gives instructions to the operating system in the form of job control statements. These commands form the user interface with the operating system.

Process Synchronisation — Basic Principles

Operating systems have so far tended to be regarded as a set of largely independent processes. After all, the tasks that are being performed are clearly defined and largely self-contained. In theory, many of these processes could be run in parallel, and if a multiprocessor system were available, then a separate processor could be allocated for each of them. In a single processor system, the processes have to be multiprogrammed. switching from one process to another according to a suitable scheduling algorithm.

Resource Management — Deadlocks

One of the major functions of an operating system is to control the resources within the computer system. Indeed, if CPU time and store are regarded as resources, then undoubtedly it is the most important function. At a slightly more mundane level, processes need to drive peripherals such as magnetic tape decks or exchangeable disk drives, as users want to mount their own media and have close and dedicated control of the peripherals. In this chapter, the problems of allocating resources to the processes in a multiprogramming system will be examined. As with the allocation of processor time and store, there is a dual objective: n n(1) n nTo implement particular management policies with respect to which users get the ‘best’ service. n n n n n(2) n nTo optimise the performance of the system.

Process Synchronisation — Advanced Techniques

It has been shown how semaphores can be used for process communication and to achieve mutual exclusion. They can, of course, be used also for more complicated synchronisation problems. The main advantage of semaphores over more ad hoc methods is that the semaphore invariant provides a means of treating synchronisation problems with mathematical rigour. It can actually be proved, rather than just assumed that the solutions are correct.

Memory Management — Paging Systems

In chapters 8 and 9 it was shown how the multiple base-limit system evolved in an effort to solve the problems inherent in the single base-limit register system. The problems of sharing and sparseness have largely been resolved, although in the case of dynamic sparseness the solution is not entirely satisfactory as whole segments have to be transferred in and out of memory in order to access just a single location. However, there are still problems with the segmented system, namely: (a) fragmentation and (b) a potential deadlock situation when a number of jobs are being multiprogrammed, since although all the processes have some of their segments in store, the number may not be enough to run (or at least to run efficiently).