25
OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL Yan hao (Wilson) Wu [email protected] University of the Western Cape Computer Science Department

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

  • Upload
    liko

  • View
    64

  • Download
    1

Embed Size (px)

DESCRIPTION

Yan hao (Wilson) Wu [email protected] University of the Western Cape Computer Science Department. OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL. The Process Model (1). Figure 2-1 (a) Multiprogramming of four programs. The Process Model (2). - PowerPoint PPT Presentation

Citation preview

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

OPERATING SYSTEMSDESIGN AND IMPLEMENTATION

Third EditionANDREW S. TANENBAUMALBERT S. WOODHULL

Yan hao (Wilson) [email protected]

University of the Western CapeComputer Science Department

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

The Process Model (1)

Figure 2-1 (a) Multiprogramming of four programs.

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

The Process Model (2)

Figure 2-1 (b) Conceptual model offour independent, sequential processes.

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

The Process Model (3)

Figure 2-1 (c) Only one program is active at any instant.

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

Process CreationPrincipal 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.

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

Process TerminationConditions that cause a process to

terminate:1. Normal exit (voluntary).2. Error exit (voluntary).3. Fatal error (involuntary).4. Killed by another process (involuntary).

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

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).

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

Process States (2)

Figure 2-2 A process can be in running, blocked, or ready state. Transitions between these states are as shown.

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

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.

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

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.

UMASK maskRoot directoryWorking directoryFile descriptionsReal idEffective UIDReal GIDEffective GIDControlling ttySave area for read/writeSystem call parametersVarious flag bits

Pointer to text segmentPointer to data segmentPointer to bss segmentExit statusSignal statusProcess IDParent processProcess groupChildren’s CPU timeReal UIDEffective UIDReal GIDEffective GIDFile info for sharing textBitmaps for signalsVarious flag bitsProcess name

RegistersProgram counterProgram status wordStack pointerProcess stateCurrent scheduling priorityMaximum scheduling priorityScheduling ticks leftQuantum sizeCPU time usedMessage queue pointersPending signal bitsVarious flag bitsProcess name

File managementProcess managementKernel

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

Interrupts

Figure 2-5 Skeleton of what the lowest level of the operating system does when an interrupt occurs.

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

Threads vs. ProcessesCreation 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.

Page 13: OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL
Page 14: OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL
Page 15: OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL

Thread (1)

Figure 2-6 (a) Three processes each with one thread.

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

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.

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

Threads (3)

Figure 2-6 (b) One process with three threads.

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

Race Conditions

Figure 2-8 Two processes want to access shared memory at the same time.

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

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

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!!!!

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

Critical SectionsNecessary 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)

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

Mutual Exclusion with Busy Waiting

Figure 2-9 Mutual exclusion using critical regions.

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

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.

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

Peterson’s Solution (1)

Figure 2-11 Peterson’s solution for achieving mutual exclusion.

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

Peterson’s Solution (2)

Figure 2-11 Peterson’s solution for achieving mutual exclusion.

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

The TSL Instruction

Figure 2-12. Entering and leaving a critical region using the TSL instruction.