NOTE: These notes are adapted from those of Allan Gottlieb, and are reproduced here, with superficial modifications, with his permission.


================ Start Lecture #1 (Jan. 23) ================

Operating Systems

2001-2002 Spring
Monday and Wednesday 12:30-1:45
Ciww 102

Chapter 0: Administrivia

0.1: Contact Information

0.2: Course Web Page

There is a web site for the course at http://cs.nyu.edu/courses/spring03/V22.0202-002/

0.3: Textbook

The course text is Tanenbaum, "Modern Operating Systems", 2nd Edition

0.4: Computer Accounts and Mailman Mailing List

0.5: Grades

Grades will computed as
.3*LabAverage + .3*Midterm + .4*FinalExam (but see homeworks below).

Midterm

We will have a midterm. As the time approaches we will vote in class for the exact date. Please do not schedule any trips during days when the class meets until the midterm date is scheduled.

0.6: Homeworks and Labs

I make a distinction between homeworks and labs.

Labs are

Homeworks are

0.6.1: Doing Labs on non-NYU Systems

You may solve lab assignments on any system you wish, but ...

0.6.2: Obtaining Help with the Labs

Good methods for obtaining help include

  1. Asking me during office hours (see web page for my hours).
  2. Asking the mailing list.
  3. Asking another student, but ...
    Your lab must be your own.
    That is, each student must submit a unique lab. Naturally changing comments, variable names, etc does not produce a unique lab

0.7: A Grade of ``Incomplete''

It is university policy that a student's request for an incomplete be granted only in exceptional circumstances and only if applied for in advance. Naturally, the application must be before the final exam.

Chapter 1

Chapter 1 of Tanenbaum has an introduction and a brief survey. I'm skipping the survey part in lecture, since it seems to me poorly structured and unnecessary. You should read this chapter through, but don't get bogged down in detail. If there's anything you have trouble with, then either we'll come back to it later, or it's unimportant.

Levels of abstraction (virtual machines)

1.1: What is an operating system?

The OS is a program that supports a virtual machine for user processes. The functionalities/abstractions provided by the OS typically include:

Topics of the course

As time permits, also

Fundamentals

Architecture

We take a highly simplified and idealized view of computer architecture, into which we will occasionally interject elements of additional reality as they become relevant. Basically we view the computer as composed of the following elements:

Modes

At any moment, the CPU is in one of two modes:

Execution

The ordinary operation of the CPU is the fetch-execute cycle:

repeat {
   fetch the instruction inst = memory[pc];
   pc++;
   execute inst
}
(Of course, this is implemented in hardware, not software.) This ordinary operation is interrupted by (obviously) interrupts . An interrupt is a signal to the CPU, usually though not necessarily issued by an I/O controller. When the CPU receives an interrupt, control immediately transfers to a specified location in the OS. (Lots of other stuff also happens; we'll describe this later.)

A process can voluntarily transfer control to the OS by executing a "trap" instruction. This is an ordinary machine-language instruction in the process code. It carries out a jump to a specified location in the OS code, and changes the mode to privileged mode. It is the only way that the process can access or jump to any address outside of its own partition of memory.

Multiprogramming

Most of this course is concerned with the implementation of multiprogramming. In multiprogramming, many processes are simultaneously resident in memory, and execution switches between processes.

The advantages of multiprogramming are the same as the commonsense reasons that in life you don't always wait until one thing has finished before starting the next thing. Specifically:

If all jobs are CPU bound and the same length, then there is no advantage in multiprogramming; you do better to run a batch system (one job at a time).

The multiprogramming environment is supposed to be invisible to the user processes; that is, the actions carried out by each process should proceed in the same was as if the process had the entire machine to itself. This raises the following issues: