OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL

1
OPERATING SYSTEMSDESIGN AND IMPLEMENTATIONThird
EditionANDREW S. TANENBAUMALBERT S. WOODHULL

• Yan hao (Wilson) Wu
• wwu_at_uwc.ac.za
• University of the Western Cape
• Computer Science Department

2
The Process Model (1)
Figure 2-1 (a) Multiprogramming of four programs.
3
The Process Model (2)
Figure 2-1 (b) Conceptual model of four
independent, sequential processes.
4
The Process Model (3)
Figure 2-1 (c) Only one program is active at any
instant.
5
Process Creation

• Principal events that cause processes to be
  created
• 1. System initialization.
• 2. Execution of a process creation system call
  by a running process.
• 3. A user request to create a new process.
• 4. Initiation of a batch job.

6
Process Termination

• Conditions that cause a process to terminate
• 1. Normal exit (voluntary).
• 2. Error exit (voluntary).
• 3. Fatal error (involuntary).
• 4. Killed by another process (involuntary).

7
Process States (1)

• Possible process states
• 1. Running (actually using the CPU at that
  instant).
• 2. Ready (runnable temporarily stopped to let
  another process run).
• 3. Blocked (unable to run until some external
  event happens).

8
Process States (2)
Figure 2-2 A process can be in running, blocked,
or ready state. Transitions between these states
are as shown.
9
Process States (3)
Figure 2-3 The lowest layer of a
process-structured operating system handles
interrupts and scheduling. Above that layer are
sequential processes.
10
Implementation of Processes
Figure 2-4. Some of the fields of the MINIX 3
process table. The fields are distributed over
the kernel, the process manager, and the file
system.
11
Interrupts
Figure 2-5 Skeleton of what the lowest level of
the operating system does when an interrupt
occurs.
12
Threads vs. Processes

• Creation of a new process using fork is
• expensive (time memory).
• A thread (sometimes called a lightweight process)
  does not require lots of memory or startup time.

13
(No Transcript)
14
(No Transcript)
15
Thread (1)
Figure 2-6 (a) Three processes each with one
thread.
16
Threads (2)
Figure 2-7. The first column lists some items
shared by all threads in a process. The second
one lists some items private to each thread.
17
Threads (3)
Figure 2-6 (b) One process with three threads.
18
Race Conditions
Definition Where two or more processes are
reading or writing some shared data and the final
result depends on who runs precisely when, are
called race condition
Figure 2-8 Two processes want to access shared
memory at the same time.
19
DANGER! DANGER! DANGER!

• Sharing global variables is dangerous two
  threads may attempt to modify the same variable
  at the same time.
• Just because you don't see a problem when running
  your code doesn't mean it can't and won't
  happen!!!!

20
Critical Sections

• Necessary to avoid race conditions
• No process running outside its critical region
  may block other processes. (not busy then in)
• No two processes may be simultaneously inside
  their critical regions. (busy then wait)
• No process should have to wait forever to enter
  its critical region. (wait only limited time)
• No assumptions may be made about speeds or the
  number of CPUs. (give up CPU while waiting)

21
Mutual Exclusion with Busy Waiting
Figure 2-9 Mutual exclusion using critical
regions.
22
Strict Alternation
Figure 2-10. A proposed solution to the critical
region problem. (a) Process 0. (b) Process 1. In
both cases, be sure to note the semicolons
terminating the while statements.
23
Petersons Solution (1)
Figure 2-11 Petersons solution for achieving
mutual exclusion.
24
Petersons Solution (2)
Figure 2-11 Petersons solution for achieving
mutual exclusion.
25
The TSL Instruction
Figure 2-12. Entering and leaving a critical
region using the TSL instruction.