CIS 303a - Computer Architecture

Chapter 11, Operating Systems


This lesson discusses common features of operating systems that relate to system development. Objectives important to this lesson:

  1. Functions and layers of an operating system
  2. Resource allocation
  3. Processes and threads
  4. CPU scheduling
  5. Memory management
Chapter 11

The chapter begins with a basic description of an operating system. It is typically a suite of programs that provide services to the system users:

  • it provides access to hardware
  • it tracks resources in the hardware (like memory and processor cycles) and allocates them to users and other programs
  • it provides access to the file system of the computer
  • it manages the GUI (Graphic User Interface), or other interfaces on older systems
  • it provides access to networks the system is connected to and to authorized resources on those networks

At some time in the past it was decided that using an operating system for these services is more efficient than having to include them in every application you load on a system. This approach saves time for developers and makes it possible to port applications from one operating system to another with less recoding.

On page 405, there is a more detailed chart of five functional areas of an operating system, and several five major concerns within each functional area. Unfortunately, the chart in the text is barely legible, so I have reproduced it here.

Operating System Functions

Hardware Interface
(device drivers)

Interrupt Processing (Supervisor) Resource allocation Services
(service layer)
Users and security
CPU Timer interrupts Scheduling Process/thread management Account management
Primary storage Page fault and protection interrupts Virtual memory management Interprocess communication Authentication
Secondary storage Storage device interrupts Storage I/O control File/folder services Authorization
I/O devices I/O device interrupts Interactive and network I/O Network services  
      Console and GUI services  


There are relationships across the four rows that I have used colors to show, and relationships down the five columns as well. For example, the text tells us that the items in the Resource Allocation column relate to users, processes started by them and for them, and resources used by those processes. It is important for the operating system to allocate time cycles, memory, storage, input, and output, and to release those resources for reallocation when they are no longer needed.

The text mentions Interrupt Processing and remarks that it is discussed in chapter 6. You may want to review that chapter if you are not familiar with the concept. An interrupt is like a direct channel to the processor, which can be used for communications that take precedence over whatever the processor might be doing. The four types of interrupts in the chart above are four kinds of events that require the processor's immediate attention.

Starting on page 406, the text talks about an operating system being organized in layers, which is another way of saying that it is modular, that it is made of lots of parts that interact with each other. The advantage of a layered system is that you can make updates to various parts of it without having to update the whole thing each time an update is needed. The diagram in Figure 11.3 may be confusing to you, so let's discuss it for a moment:

  • A user typically runs application programs, which may interface with the command layer or the service layer of the operating system.
  • A user may also interface with the command layer of the operating system directly.
  • The command layer of the operating system is often called the shell. It may include a graphic user interface (GUI) or a character-based user interface (CUI). This layer is where the user starts applications, manages files and folders, and accesses devices that are part of the system.
  • The service layer manages the housekeeping of the system, and provides services to applications. This means that an application programmer does not have to write machine-specific code to print, open and close files, or manage output to the user's display. The application only has to make generic function calls (service calls) to code in the service layer of the operating system that carries out the machine specific tasks that the device requires.
  • The kernel is the innermost layer of the operating system. It includes device drivers that act as interfaces between specific hardware and the operating system.

The text backtracks on page 409, discussing the history of resource allocation. At one time, computers could only run one application at a time (in addition to running the operating system), which gave that one application access to all of the system's resources: processor cycles, memory, and devices.

Computers improved and so did operating systems, which led to several methods of sharing a computer's resources between several running programs. Sometimes a resource is allocated for a short time to each application, and sometimes a portion of a resource (like a section of RAM, or a part of the processor) is allocated to each of several running programs, which is an example of a true multitasking state. More often, resource allocation is more like sharing and taking turns for short time intervals. Memory, for example, can be allocated to a program (committed), then deallocated (released) when it is no longer needed, making it available for allocation to the next program that needs such a resource.

On page 411, the text describes real and virtual resources. In short, a system's real resources are those that are actually installed or connected to it: memory, processor abilities, storage capacity, input devices, and output devices are examples. Each of the system's resources may appear to a running application as one hundred per cent available to that application, regardless of the number of applications actually competing for resources. That is an example of virtual resources. Every resource appears to be available to every application at all times, and it is up to the operating system to allocate and deallocate the real resources so that they are shared appropriately. The text talks about the positive aspects of this approach, but there are negative ones as well. You may have turned on a computer at some time and been confronted with several windows proclaiming that there were updates you needed to install for several programs, all of which wanted attention before the system was actually communicating on your network. This is an artifact of granting applications virtual access to system resources. The concept works smoothly as long as no application wants a resource for very long, and as long as the resource is actually available.

In a Technology Focus sidebar on pages 412 and 413, the text discusses running virtual machines, which means using specialized software to make your computer act like two or more computers. The advantage to doing this is that you can run a different operating system in each virtual machine, and that if anything causes one of them to crash, you just restart it from the saved image that it boots from. On a large server, you might do this several times, allowing each virtual machine to act like a separate device that will not affect the others if anything goes wrong.

The generic term used in the text for an OS feature that can run virtual machines is hypervisor.

Back to the concept of resource management, the text describes process control blocks (PCBs) on page 413. These are data structures that hold information about resources that are allocated to each process running in memory. We are told that a process is a unit of software that is being executed. When a process is loaded in memory and run, a PCB is created for it. The PCB is updated every time resources are allocated or deallocated to that process. The PCB also holds the current state of the process and the name of the process's owner. All current PCBs can be held in a process queue (process list) that is searched each time a user logs off, so processes owned by that user can be stopped.

Processes can start (spawn) other processes, which creates parent/child relationships between them. Processes can also be subdivided into threads, which is done when those threads can be managed and run independently. When this is done, data on each thread is kept in a thread control block (TCB). A process that splits into multiple threads is called a multithreaded process.

Figure 11.7 on page 415 show how several threads might share time slices on a single processor, depending on the priority assigned to each thread. The text refers to this method as concurrent execution and as interleaved execution. The second phrase seems more apt, since no two threads are actually being executed at the same time in this case.

On page 416, the text discusses thread states. The three shown are important:

  • ready - A thread is ready when it is created, and it is waiting to be given time on the CPU. When the OS sees the CPU is available, it gives control to one of the ready threads. (This is called dispatching.)
  • running - When a thread has control of the CPU, the thread is running. It leaves this state when it is done, or when there is an interrupt, which places it in the blocked state.
  • blocked - A thread is blocked when an interrupt occurs. Three types are listed on the top of page 417: service calls, hardware interrupts, and peripheral device interrupts. On the next page, the text describes an interrupt being generated by the OS scheduler. We have already seen that threads must share a CPU, so the programmer should expect them to be blocked for this reason regularly.

Scheduling of threads and processes is discussed on page 418. The author talks about three types:

  • preemptive - A thread can be changed from the running state to a blocked state when an interrupt happens. The thread is pushed onto the stack of instructions waiting for CPU time. Control of the CPU is handed to the OS supervisor, which calls an event handler, and hands control of the CPU to the scheduler.
    • timer interrupts - These are built-in interrupts that let the OS determine that no thread is stuck in a loop, holding up the CPU. During one of these mandatory interrupts, the scheduler can give control to another thread or process.
  • priority-based - Can schedule a thread to take over the CPU based on one of three reasons:
    • first come, first served - May also be considered to be first in, first out (FIFO). The thread that has been waiting for CPU time the longest is scheduled next.
    • explicit priority - Threads can be assigned a priority value based on the priority of their application or their owner. They can be moved ahead of other threads, or given more time slots than other threads.
    • shortest time remaining - The thread that will take the shortest time to finish can be given priority over others.
  • real-time - A thread can request real-time scheduling when the thread is created, which is like requesting a priority to guarantee completion in specific time. The text mentions that this can be useful for transaction processing, data acquisition, and automated process control. An automated teller machine is given as an example of a device requesting this kind of scheduling for a transaction.

On page 427, the text discusses memory allocation, which is the last major topic in the chapter. It is defined as assigning specific memory addresses to specific programs (OS programs or applications) and data. The text notes that this activity applies to RAM and to storage devices as well.

The text begins by reminding us that we can imagine a computer's memory as a series of adjacent, numbered cells, and that the numbers are applied sequentially. Data elements, such as variables, usually occupy more than one byte. We can say that an object stored in a sequence of bytes has a most significant byte and a least significant byte. The least significant byte is usually stored at the lowest memory address allocated to the object. This is called the little endian method. The reverse, storing the most significant byte at the lowest available address is called the big endian method.

Addressable memory is the total series of addresses that your operating system can use. It is defined by highest address your operating system supports. The text says that your computer may contain less installed memory (physical memory) than this number, but it cannot contain more. It would be more accurate to say that the operating system cannot use more memory than its address space supports.

Once it has established these basics, the text tells us that the OS tracks the memory allocations it makes to processes and threads in tables, which is reminiscent of method it uses to track the states of processes and threads.

The text has given us the impression that memory is always allocated in sequential (contiguous) address ranges, but this is not always possible. Memory is allocated, used, and released for reallocation constantly, which leads to the state in which enough memory for a purpose is available, but it is only available in separate chunks. Even when contiguous memory is available, it may not be available in range that the program prefers, so the OS makes the allocation to the process, makes it look like it is located in low memory, but uses an offset value that refers to the real starting memory address. The text refers to this value as the process offset for that process.

The text also discusses virtual memory management, which uses storage device memory as swappable space for RAM. This is often done on devices running Windows. A process is divided into parts called pages. Space in RAM that holds a page (part of a process) is called a page frame. Pages that are not currently in use can be copied to space on a hard drive called swap space, swap files, or page files. This allows the OS to free up the page frame that the copied page was using, and to load a page that is needed next into that page frame.