CS 321 Spring 2013  >  Lecture Notes for Friday, January 18, 2013

CS 321 Spring 2013
Lecture Notes for Friday, January 18, 2013

Course Overview

The Main Idea

This class is about:

In particular, we are not here to do a survey of the various OSs out there. We will consider concepts from the point of view of low-level applications programming. Most of our practical examples will involve Linux, or, more generally, the *ix family of operating systems.

Three Abstractions

In this class we will focus on three abstractions that operating systems provide.

Processes/Threads
All modern OSs place an abstraction around the processor. A process is a program in execution. In practice, we generally use the word “process” only when memory space is not shared. If a common memory space is used, then we call them threads.
Address Spaces
Address spaces are abstractions built around the system memory. Each process has its own, and, to the process, it appears as if it has access to the entire memory of the machine. Often, the address space is larger than the physical memory of the machine; through a mechanism called virtual memory the contents of part of memory can be swapped out to disk if it is not currently needed.
File Systems
A disk has a large number of magnetized regions, which can be interpreted as zeroes and ones. On top of this, the OS builds something that looks like a collection of documents, with a directory structure, names, sizes, permissions, etc.

Course Topics

We will proceed through the text largely in order, covering much of the first six chapters. After the introductory material, there will be one chapter on each of the above abstractions. Then we look at some of them in more detail.

Introduction to Operating Systems

Terminology

When we do abstraction, we deal with something through a well-defined interface, without having to worry (much) about what is behind the interface. For example, a function is an abstraction. We call a function, passing it the appropriate parameters, without having to know exactly what its body looks like.

We use the word “virtual” to refer to things having the same interface, possibly with different things behind the interface. For example, we usually deal with the system keyboard using a virtual file.

We used a Linux shell to look at examples of virtual files: keyboard input, screen output, pipes, named pipes.

Here are some examples.

cat < abc > def1
sort < abc > def2
uniq < abc > def3

Each of the above three command lines reads from file abc and writes to a def... file. The first sends the contents of abc to file def1, unchanged. The second sorts by line before writing. The third removes duplicate consecutive lines before writing. The arrows (“<”, “>”) indicate the direction of data flow.

cat > def

The above reads from the terminal (keyboard?) used as a virtual file. and writes to file def.

sort < abc

The above reads from file abc, sorts by line, and writes to the terminal, used as a virtual file.

cat < abc | sort | uniq

The above reads from file abc, sorts by line, removes duplicate lines, and writes to the terminal. This comamnd line includes two uses of a pipe: a virtual output file connected to virtual input file.

mkfifo mypipe
cat < abc | sort > mypipe

And then, in another terminal window:

cat < mypipe | uniq

The above two together have the same effect as before, but they create and use the named pipe mypipe. This is much like the pipe used earlier, except that looks like a file in the current directory.

Source files halflines.cpp [C++ source] and revlines.cpp [C++ source] were used in class.

What is an Operating System?

The obvious question is “What is an operating system?” But we will not answer it. We prefer to ask, “What do operating systems do?” Then we will spend the semester discussing how to do those things.

We can divide the answers to our question into two categories.

The various software packages that we usually call “operating systems” (Windows, MacOS, Linux, iOS, Android, etc.) fit the above ideas very well. But web browsers do, too; they provide services to the programs (usually written in Javascript) that are executed in them. So, is Mozilla Firefox an operating system? Maybe, but does it matter? Not really.

Why Have an Operating System?

There are essentially four reasons to have an OS.

Convenience
Operating systems provide services, like process scheduling and memory management, that nearly all application programs will need. They provide them in a consistent manner.
Uniform Interface
Using an operating system, we can access all kinds of (say) storage devices through a common interface. So we do not need to worry about exactly what brand of disk drive we are using. Often, through this same interface, we can access other things. For example, resources accessed via a network can be made to appear as disks.
Scarcity
A computer system has a limited amount of memory, processor time, storage, etc. Every program wants all of it. The OS helps to make sure that each program gets some.
Protection
Buggy or malicious code might attempt to access or alter resources that should not be accessed. Modern OSs include protection mechanisms to prevent unauthorized access.

Note that the first two reasons above relate mainly to the OS’s role as an extended machine, with the last two relate mainly to the resource-manager role.

A Model of a Computer System

We can divide a computer system into four parts: application programs, operating system, hardware, users. The applications interact only with the OS. Users interact only with the hardware. The OS functions as an interface between the applications and the hardware. A diagram is shown below.

Image not displayed: diagram of computer system

Note that users might feel as if they are interacting directly with an application; but they never actually do. Thus, an important responsiblity of an OS is to represent the user to applications.


CS 321 Spring 2013: Lecture Notes for Friday, January 18, 2013 / Updated: 22 Jan 2013 / Glenn G. Chappell / ggchappell@alaska.edu