1.2 History of Operating Systems

1. Single user (no OS).
2. Batch, uniprogrammed, run to completion.
   • The OS now must be protected from the user program so that it is capable of starting (and assisting) the next program in the batch).
3. Multiprogrammed
   • The purpose was to overlap CPU and I/O
   • Multiple batches
     • IBM OS/MFT (Multiprogramming with a Fixed number of Tasks)
       • The (real) memory is partitioned and a batch is assigned to a fixed partition.
       • The memory assigned to a partition does not change
     • IBM OS/MVT (Multiprogramming with a Variable number of Tasks) (then other names)
       • Each job gets just the amount of memory it needs. That is, the partitioning of memory changes as jobs enter and leave
       • MVT is a more ``efficient'' user of resources but is more difficult.
       • When we study memory management, we will see that with varying size partitions questions like compaction and ``holes'' arise.
   • Time sharing
     • This is multiprogramming with rapid switching between jobs (processes). Deciding when to switch and which process to switch to is called scheduling.
     • We will study scheduling when we do processor management
4. Multiple computers
   • Multiprocessors: Almost from the beginning of the computer age but now are not exotic.
   • Network OS: Make use of the multiple PCs/workstations on a LAN.
   • Distributed OS: A ``seamless'' version of above.
   • Not part of this course (but often in G22.2251).
5. Real time systems
   • Often in embedded systems
   • Soft vs hard real time. In the latter missing a deadline is a fatal error--sometimes literally.
   • Very important commercially, but not covered much in this course.

Note:
There was a tiny typo in the lab the line

 1        1888 ->x           1002

 1        1888 ->xy          1002

1.3: Operating System Concepts

This will be very brief. Much of the rest of the course will consist in ``filling in the details''.

1.3.1: Processes

A program in execution. If you run the same program twice, you have created two processes. For example if you have two editors running in two windows, each instance of the editor is a separate process.

Often one distinguishes the state or context (memory image, open files) from the thread of control. Then if one has many threads running in the same task, the result is a ``multithreaded processes''.

The OS keeps information about all processes in the process table. Indeed, the OS views the process as the entry. An example of an active entity being viewed as a data structure (cf. discrete event simulations). An observation made by Finkel in his (out of print) OS textbook.

The set of processes forms a tree via the fork system call. The forker is the parent of the forkee. If the parent stops running until the child finishes, the ``tree'' is quite simple, just a line. But the parent (in many OSes) is free to continue executing and in particular is free to fork again producing another child.

A process can send a signal to another process to cause the latter to execute a predefined function (the signal handler). This can be tricky to program since the programmer does not know when in his ``main'' program the signal handler will be invoked.

1.3.2: Files

Modern systems have a hierarchy of files. A file system tree.

• In MSDOS the hierarchy is a forest not a tree. There is no file, or directory that is an ancestor if both a:\ and c:\.
• In unix the existence of symbolic links weakens the tree to a DAG

Files and directories normally have permissions

• Normally have at least rwx.
• User, group, world
• More general is access control lists
• Often files have ``attributes'' as well. For example the linux ext2 filesystem supports a ``d'' attribute that is a hint to the dump program not to backup this file.
• When a file is opened, permissions are checked and, if the open is permitted, a file descriptor is returned that is used for subsequent operations

Devices (mouse, tape drive, cdrom) are often view as ``special files''. In a unix system these are normally found in the /dev directory. Often utilities that are normally applied to (ordinary) files can be applied as well to some special files. For example, when you are accessing a unix system using a mouse and do not have anything serious going on (e.g., right after you log in), type the following command

    cat /dev/mouse

Many systems have standard files that are automatically made available to a process upon startup. These (initial) file descriptors are fixed

• standard input: fd=0
• standard output: fd=1
• standard error: fd=2

A convenience offered by some command interpretors is a pipe or pipeline. The pipeline

  ls | wc

1.3.3: System Calls

System calls are the way a user (i.e. a program) directly interfaces with the OS. Some textbooks use the term envelope for the component of the OS responsible for fielding system calls and dispatching them. Here is a picture showing some of the OS components and the external events for which they are the interface.

Note that the OS serves two masters. The hardware (below) asynchronously sends interrupts and the user makes system calls and generates page faults.

What happens when a user executes a system call such as read()? We discuss this in much more detail later but briefly what happens is

1. Normal function call (in C, Ada, Pascal, etc.).
2. Library routine (in C).
3. Small assembler routine.
   1. Move arguments to predefined place (perhaps registers).
   2. Poof (a trap instruction) and then the OS proper runs in supervisor mode.
   3. Fixup result (move to correct place).