NOTE: These notes are adapted from those of
Allan Gottlieb, and are
reproduced here, with superficial modifications, with his permission.
================ Start Lecture #1
Monday and Wednesday 12:30-1:45
Chapter 0: Administrivia
0.1: Contact Information
- email@example.com (best method)
- Warren Weaver Hall, room 429
0.2: Course Web Page
There is a web site for the course at
The course text is Tanenbaum, "Modern Operating Systems", 2nd Edition
- The first edition is not adequate as there have been many
- Available in bookstore.
- We will cover nearly all of the first 6 chapters.
0.4: Computer Accounts and Mailman Mailing List
- You are entitled to a computer account, please get it asap.
- Sign up for the Mailman mailing list for the course.
- If you want to send mail just to me, use firstname.lastname@example.org not
the mailing list.
- Questions on the labs should go to the mailing list.
You may answer questions posed on the list as well.
- I will respond to all questions; if another student has answered the
question before I get to it, I will confirm if the answer given is
Grades will computed as
.3*LabAverage + .3*Midterm + .4*FinalExam (but see homeworks below).
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.
- Due several lectures later (date given on assignment).
- Graded and form part of your final grade.
- Penalized for lateness.
- Computer programs you must write.
- Due one week later.
- Not accepted late.
- Mostly from the book.
- Collected and returned.
- Can help, but not hurt, your grade.
0.6.1: Doing Labs on non-NYU Systems
You may solve lab assignments on any system you wish, but ...
- You are responsible for any non-nyu machine.
I extend deadlines if the nyu machines are down, not if yours are.
- Be sure to upload your assignments to the
- In an ideal world, a program written in a high level language
like Java, C, or C++ that works on your system would also work
on the NYU system used by the grader.
Sadly this ideal is not always achieved despite marketing
claims that it is achieved.
So, although you may develop you lab on any system,
you must ensure that it runs on the nyu system assigned to the
- If somehow your assignment is misplaced by me and/or a grader,
we need a to have a copy ON AN NYU SYSTEM
that can be used to verify the date the lab was completed.
- When you complete a lab (and have it on an nyu system), do
not edit those files. Indeed, put the lab in a separate
directory and keep out of the directory. You do not want to
alter the dates.
0.6.2: Obtaining Help with the Labs
Good methods for obtaining help include
- Asking me during office hours (see web page for my hours).
- Asking the mailing list.
- 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 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)
- Software (and hardware, but that is not this course) is often
implemented in layers.
- The higher layers use the facilities provided by lower layers.
- Alternatively said, the upper layers are written using a more
powerful and more abstract virtual machine than the lower layers.
- Alternatively said, each layer is written as though it runs on the
virtual machine supplied by the lower layer and in turn provides a more
abstract (pleasent) virtual machine for the higher layer to run on.
- Using a broad brush, the layers are.
- Applications and utilities
- Compilers, Editors, Command Interpreter (shell, DOS prompt)
- The OS proper (the kernel, runs in
- Compilers, editors, shell, loader. etc run in user mode.
- The term OS is not well defined. Is it just the kernel? How
about the libraries? The utilities? All these are certainly
system software but not clear how much is part of the OS.
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:
- Multiprogramming. Many processes can run on the same machine,
dividing the memory, and alternating time-slices, each essentially
unaffected by the existence of the others. About 3/4 of this course
deals with the question of how multiprogramming is achieved.
- Virtual memory. A process can reference an address space that
is larger than the physical RAM.
- File system. A process can deal with files in the abstract,
without worrying about the details of the hardware that supports the
files, its interaction with the main processor, or the implementation
of the file system.
- Abstract I/O. A process can carry out I/O (a) without worrying
about numerous grungy details; (b) without caring much about what actual
I/O device it's interacting with. The degree to which (b) is achieved
or achievable is very variable, depending on the particular device.
- Security. User processes are prevented from carrying out destructive or
- System interface. Some mode exists for the user and user processes
to make requests of the system. The direct interface between the user
and the OS is called the shell.
Topics of the course
As time permits, also
- Process management for multiprogramming.
- Process model
- Context switching
- Interprocess communication -- semaphores
- Memory management
- Disks and file systems
- Other I/O
- Distributed systems
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
- CPU. Does the actual computation. Includes in particular a collection
of registers. The program counter (PC) is a register that holds
memory address of the memory address to be executed.
- Memory. Volatile, rapid access memory (RAM). The OS and the active
part of user processes are resident in RAM.
- Memory management unit (MMU). Translates virtual addresses
found in the user code to physical addresses in memory.
- Device controllers. Interface between the CPU and I/O devices.
- Busses. Information flow between these various components occurs over
At any moment, the CPU is in one of two modes:
- User mode. Only addresses within the user space can be accessed.
Only a limited class of instructions can be executed. Peripheral devices
cannot be accessed.
- Privileged or kernel mode. All addresses can be accessed, and all
instructions can be executed.
The ordinary operation of the CPU is the fetch-execute cycle:
fetch the instruction inst = memory[pc];
(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.
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).
- 1. More efficient use of computer time. If the computer is running a single
process, and the process does a lot of I/O (either disk or interacting with
a human), then the CPU is idle most of the time. For instance, a
computer running text editor goes a cycle of responding to the charater
entry, which generally takes a fraction of a microsecond, and then waiting
for the next character, which takes at least 50 milliseconds. So the
CPU is idle 99.9% of the time. Thus, the same computer can in principle
support 1000 users simultaneously running text editors by
time-sharing -- switching from one to another. (In practice a couple
of hundred users is more realistic.) This is a gain as long as some
of the jobs are I/O bound -- spend most of their time waiting
- 2. Faster turnaround if there are jobs of different lengths. Consideration
(1) applies only if some jobs are I/O bound. Consideration (2) applies even
if all jobs are CPU bound. For instance, suppose that first job A, which takes
an hour, starts to run, and then immediately afterward job B, which takes 1
minute, is submitted. If the computer has to wait until it finishes A before
it starts B, then user A must wait an hour; user B must wait 61 minutes;
so the average waiting time is 60-1/2 minutes. If the computer can switch
back and forth between A and B until B is complete, then B will complete after
2 minutes; A will complete after 61 minutes; so the average waiting time
will be 31-1/2 minutes.
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
- Process model: The state of an inactive process has to be encoded and saved
in a process table so that the process can be resumed when made
- Context switching: How does one carry out the change from one
process to another?
- Memory translation: Each process treats the computer's memory as its
own private playground. How can we give each process the illusion that
it can reference addresses in memory as it wants, but not have them
step on each other's toes? The trick is by distinguishing between
virtual addresses --- the addresses used in the process code --
and physical addresses -- the actual addresses in memory. Each
process is actually given a fraction of physical memory. The MMU (memory
management unit) translates the virtual address in the code to a
physical address within the user's space. This translation is invisible to
- Memory management: How does the OS assign sections of physical memory
to each process?
- Scheduling: How does the OS choose which process to run when?