CS 149: Operating Systems
January 29 Class Meeting
Department of Computer Science
San Jose State University
Spring 2015
Instructor: Ron Mak
www.cs.sjsu.edu/~mak
Example System Call: fork()
#include <stdio.h>
forktest.c
main()
{
printf("Parent: Process started.\n");
printf("Parent: Forking a child.\n");
if (fork() != 0) {
The two processes fork at this point.
int status;
printf("Parent: Waiting for child to complete.\n");
waitpid(-1, &status, 0);
printf("Parent: Child has completed.\n");
Executed by the parent.
printf("Parent: Terminating.\n");
}
else {
printf("Child: Process started.\n");
printf("Child: Start 10 second idle:");
int i;
for (i = 10; i >= 0; i--) {
printf("%3d", i); fflush(stdout);
sleep(1);
}
printf(" done!\n");
printf("Child: Terminating.\n");
Executed by the child.
}
}
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
2
The waitpid() System Call
waitpid(-1, &status, 0);
Pass the address of variable status
(i.e., pass by reference).

What are the parameters?

Use the command-line UNIX man (for
“manual”) command to get documentation
of any system command or API call.
_
Demo
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
3
Shell: I/O Redirection

For a program run on the command line:


Standard input (stdin) is the keyboard.
Standard output (stdout) is the terminal.
echo.c
#include <stdio.h>
#define MAX_LENGTH 256
main(int argc, char *args[])
{
char *progname = args[0];
char line[MAX_LENGTH];
}
This program reads lines of text
from stdin and echos them to
stdout after prepending each
line with the program name.
while (gets(line) != NULL) {
printf("%s: %s\n", progname+2, line);
}
Why the +2?
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
4
Shell: I/O Redirection

You can redirect a program’s stdin on the
command line with the < operator:
./echo < echo.c


Now the echo program will read its own source file.
You can redirect a program’s stdout on the
command line with the > operator:
./echo < echo.c > echo.txt



Now the echo program will write to file echo.txt.
Use the >> operator to append to an output file.
You can redirect both stdout and stdin.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Demo
5
OS Concept: Pipes

Pipes are a mechanism for
interprocess communication (IPC).



One process writes to one end of a pipe.
Another process reads from the other end.
Each process believes it is doing file I/O.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
6
Shell: Piping

You can pipe a program’s output to another
program with the | operator:
./echo1 | ./echo2


The first program’s stdout becomes
the stdin for the second program.
What’s the result of this command?
./echo1 < echo.txt | ./echo2 | ./echo3
Demo
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
7
The POSIX Standard

POSIX (Portable Operating System Interface)

IEEE standard for system calls.

Maintain compatibility among operating
systems.

UNIX and non-UNIX
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
8
Process Management System Calls

POSIX system calls.

Most modern operating systems have
system calls that perform these functions.

However, details may differ.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9
All rights reserved
9
File Management System Calls
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9
All rights reserved
10
File System Management System Calls
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9
All rights reserved
11
Miscellaneous System Calls
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9
All rights reserved
12
Kernel Mode vs. User Mode

An OS such as UNIX executes its
critical system software in kernel mode.


As a user, you run utility programs
(such as editors, compilers, and browsers)
and application programs in user mode.


This is one way the OS protects itself.
System calls made by your programs can invoke
some OS code that is executed in kernel mode.
On the command line, you can become
“super user” and bypass some of the
OS protection mechanisms.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
13
Workflow of a System Call
Invoke the system call
count = read(fd, buffer, nbytes)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Push nbytes
Push &buffer
Push fd
Invoke the read
library routine.
Put the system call code
for read in a register.
TRAP instruction switches
to kernel mode to access
the dispatcher in the
OS kernel.
Dispatcher accesses the
read handler.
Execute the read handler.
Return to the user program
at the point after the TRAP
instruction.
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
14
Operating System Structure

There are various ways to organize the code
of an operating system.





Monolithic
Layered
Virtual machines
Client-server
Distributed
_
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
15
OS Structure: Monolithic

The original classic way an OS was designed.

No structure.



A collection of routines.
Each routine can call any other routine.
No information hiding.

A challenge to build and link.

An even bigger challenge to maintain and debug.
Every software engineer should read the book
The Mythical Man-Month about the development of IBM OS/360.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
16
OS Structure: Layered

Organize the OS as a hierarchy of layers.

Each layer built on top of the one below it.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
17
OS Structure: Layered

Layers of the THE operating system.


For a Dutch computer in the late 1960s.
The bottommost layer 0 provided multiprogramming.
_
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
18
OS Structure: Virtual Machines

Virtual machines (VMs) were first developed
for the IBM 370 in the late 1960s.


Each virtual machine behaves like
a separate physical machine.
Controlled by a virtual machine monitor.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
19
OS Structure: Virtual Machines

Modern VM monitors include:





VirtualBox
VMware
KVM
OpenVZ
Xen
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
20
OS Structure: Client-Server

Put as much OS code as possible
outside of the kernel and into user space.

OS services run as separate processes.


Processes send messages to each other to request services.
A “microkernel” serves as the communications bus.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
21
OS Structure: Distributed

Like client-server, except that server processes
run on different machines on the network.


Service request messages go over the network.
User programs do not need to know
where the services are provided.
_
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
22
Processes

A process is basically an
abstraction of a running program.


The most central concept in any operating system.
Each process runs in its own address space.
_
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
23
Process Models

Multiprogramming with
multiple programs.

One program counter
per CPU.

Each program has its
own virtual CPU.

The real CPU rapidly
switches from one
program to another.

Process switching
AKA context switching
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
24
Process Models, cont’d

Only one program is active on a CPU
at any instant.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
25
Context Switching
A process’s state
information is kept
in its process control
block (PCB).
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
26
Process Creation

Principal events that cause
processes to be created:

System initialization.

Execution of a process creation system call
by a running process.

fork()

A user request to create a new process.

Initiation of a batch job.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
27
Process Termination

Conditions that cause a process to terminate:





Normal exit (voluntary).
Error exit (voluntary).
Fatal error (involuntary).
Killed by another process (involuntary).
Cascading termination

On some operating systems, when a process
terminates, so do its child processes.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
28
Process Creation and Termination
What does the exec()
system call do?
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
29
Process States

Running


Ready


Actually using the CPU at that instant.
Runnable, but temporarily stopped to let another process run.
Blocked

Unable to run until some external event happens.
Computer Science Dept.
Spring 2015: January 29
CS 149: Operating Systems
© R. Mak
Operating Systems: Design and Implementation, 3rd ed.
Andrew Tanenbaum & Albert Woodhull
(c) 2006 Prentice-Hall, Inc. 0-13-142938-8
30