Operating Systems: an Overview

Chapter 15

Operating Systems: An Overview

15.1(BL1+) Without an operating system, there are no I/O device drivers, therefore there is no user interface for typing in commands, nor any display for output, until the user's program is running. There is also no way to load files built into the computer. There must be a way to boot the system, but this might involve loading a bootstrap loader into memory by hand, from switches on the front panel of the computer, for example. Once a simple loader is stored in memory, it can be used to load and execute programs. Once the program is complete, however, it will probably halt, and the user will have to go through the procedure each time. Such niceties as multitasking and multiuser operation, logical file systems, program services, and a user interface to the system are obviously not possible.

15.2(BL2-) The most popular commands in MS-DOS would certainly include DIR, TYPE, COPY, DEL, CD. In UNIX, the equivalent commands, ls, cat, cp, rm, and cd would also be among the most popular. Each of these commands is a request to the file system, ultimately resulting in one or more I/O requests to the appropriate device or devices. For example, the DIR command would read the directory file on a particular device. It would also have to send the listing to the display. Because of their intensive usage, one would assume that these commands are memory resident, whereas rarely used commands such as FORMAT would be loaded only when needed. UNIX systems take a different approach, however, and load most commands as they are needed, rather than keeping them in memory. (Only commands resident to a shell stay resident in memory.)

15.3(BL2+) Running programs concurrently requires the manipulation of resources to satisfy each of the programs, particularly management of memory to hold multiple programs, and CPU scheduling, so that each program gets its fair share of execution time in a way that work proceeds smoothly to the user's perspective. The sharing of files and other I/O resources must also be considered.

15.4(BL2-) Providing a BIOS in ROM means that the I/O driver software must be generic enough to handle different situations as they arise. It also means that features cannot be added easily to the I/O driver with technological advances, nor can the driver be easily replaced with a newer version. In such cases, it is often necessary to replace the BIOS to acquire newer services.

15.5(BL2) As a user, you might wish to replace the Windows interface shell with one more amenable to your specific individual needs. However, the average user would be inconvenienced by the unfamiliarity of a different shell and the learning curve required to do productive work in a new shell. (These are also considerations in the replacement of applications with new ones that have a different interface.) So, replacement of the shell would have to be at the individual user's discretion and choice.

15.6(BL2-) Processes can be executed concurrently when one or more processes are blocked waiting for I/O, or when the operating system supports time-slicing. The execution of a process while other processes are waiting for I/O keeps the CPU busy with little overhead. Since many processes are blocked simply because they are waiting for keyboard input from a user, this is an efficient way to increase the number of processes that can execute concurrently. Time-slicing allows a number of processes to share the CPU, creating the impression that they are executing simultaneously. Although each process executes more slowly, the overall gain in user productivity makes time-slicing worthwhile as a means of concurrency. Concurrency allows a user to be working at several tasks simultaneously, or allows multiple users to share the use of a system.

15.7(BL2-) An event-driven program is one that responds to events as they occur, rather than performing any work on its own. For example, in a preemptive system the dispatching operation responds to interrupts by a clock that result in the dispatching operation selecting a candidate to execute. In a nonpreemptive system, the dispatcher responds to the event that the process running has completed execution.

15.8(BL2) The logical view of the file is the organization of the file as it appears to the user or to the application program. The physical view of the file is the organization of the file for storage.

15.9(BL2) By separating the file system from the I/O services it becomes possible to modify one part of the system without affecting the other. Thus, it becomes possible to add new I/O devices and services without affecting the organization and operation of the file system. Isolating the file management from I/O services also makes it possible to treat all files similarly, regardless of the device that they are stored on, and to relocate and copy files from one device to another.

15.10(BL2) Both memory allocation and disk space allocation result in fragmentation because the space available for a program or file is not normally the same as the size of the file or program that will use the space. In both cases, compaction can be used to collect the available spaces together for more efficient use. Memory compaction is difficult to achieve, because programs must be relocated while they are executing. Disk compaction, known as defragging, is practical. A major difference is that using conventional memory, with no virtual storage, requires a program to be loaded contiguously, which means that sufficient contiguous space must be available to be able to load the program. Disk files can be stored noncontiguously, which means that available space can be used more effectively.

15.11(BL2) Since Windows 3.1 can not preempt a program that is running, it is possible for an uncooperative program to hog the system. Worse yet, a program with a major bug, such as an infinite loop or other deficiency that disables the user's ability to stop the program and also disables the program's cooperation mechanism, may "hang" the system, and force the user to reboot the system, destroying any work that has not been saved.

15.12There is no general solution to this problem. The solution depends on the installation at the student's institution.

15.13(BL3) The minimum kernel must provide basic interrupt-handling capability, as well as basic process or thread management functions, including particularly memory management and scheduling functions. Interprocess communication is also required, bnt this discussion is beyond the scope of this textbook.

15.14See problem 6.14

15.15(BL3) By hiding most of its configuration in the Registry, Windows prevent users from modifying the configuration of a system unintentionally, thereby protecting the system from modifications that could result in system instability. Conversely, the difficulty in hiding the configuration in the Registry makes it difficult for even an expert administrator from making modifications that could repair problems or improve performance. Indeed, applications can modify the Registry in such a way as to cause conflicts between programs that are difficult to repair. Well-documented text-based configuration files make it possible to locate and repair potential problems easier and more rapidly, but must still be hidden from the average user to prevent destructive tampering.

15.16(BL3) The list of most active files indicates that these files might be divided among different disks to equalize the load on each and to provide more efficient I/O. The usage of physical memory indicates that it may be necessary in the future to provide additional memory, or to find an alternative way to use memory more efficiently, perhaps by the more efficient use of virtual storage. The table of I/O operation rate by disk indicates that disk 0 is used heavily compared to other disks; it might be possible to distribute its workload more effectively among the available disks. According to the report, disk 7 is also overutilized. It also appears that disk 4 is out of service, which might require attention if this is not intentional. The report also indicates a disk fragmentation problem that may require attention.

15.17(BL2) On a system that is used with real-time processes, the multitasking must allow the scheduler and dispatcher to preempt processes quickly to allow the real-time processes immediate access to CPU time when they request it. Furthermore, the real-time tasks must be able to remain in memory, even if other tasks must be swapped out to make space available. (In virtual storage systems, the real-time processes will usually reside totally in real memory, with their pages locked, so that the process will never have to wait for pages. This is necessary because the wait for pages may exceed the critical times required by the process. This issue is considered again in Chapter 16.)

15.18(BL2) The operating system in an automobile would not require file management or secondary storage management, since those functions do not exist in an automobile. Memory management would also not be required, because the programs are permanently resident. Multitasking is required to manage the different operations in the automobile. I/O and interrupt control are important functions, to handle the car's reaction to different driving and engine conditions. System administration support is present to make it possible to analyze automobile malfunctions. There is also a minimal user interface for this purpose.

15.19(BL1+) Multiprogramming or multitasking is the ability to execute more than one process concurrently on a single CPU. Multiuser is multitasking that is designed to allow multiple users to execute processes concurrently on the system. Multiprocessing is the condition where multiple CPUs are available to execute processes simultaneously. In addition to its other tasks, the operating system scheduler in a multiprocessing system directs processes to the different CPUs as they become available for execution.

15.20(all BL3)

a.The list of active processes gives the administrator the processes that require the most memory and the processes that consume the most CPU time. As a result of this data, the administrator may restrict iengland’s access to the system during peak hours of system activity, or may ask iengland to run his programs at a lower priority so that other users will have adequate performance.

b.The average process data, as shown in the load chart, indicates that system use peaks sharply at certain times of the day. This suggests that for optimal system utiolization, batch processes would most effectively be run during the valley periods. The peaks and valleys indicate that the system is not well balanced in its usage. Overall, the system has spare capacity, but not during peak times.

c.Each window provides data from a different perspective. The graphical load data gives a quick view of how well the system is utilized. In contrast, the process lists are predominantly tabular, offering more detail that requires careful analysis. The upper process graph also provides a quick overview summary of memory use, which may be useful because it combines processes that work together into single visual spaces. (See, for example, the kdeinit process, which is broken into twelve process pieces in the lower tabled.)