Slide 1-1

Computer Systems IIGordon College

Operating System Overview

Class Intro Operating System Class Two Directions: Practical Linux+ Guide to Linux Certification and Lab Manual Lab Experience

Slide 1-2

Theoretical Operating Systems (3rd Edition Gary Nutt) Lecture and Projects

1

Why Study Operating Systems? Understand the model of operation Easier to see how to use the system Enables you to write efficient code

Slide 1-3

Learn to design an OS Even so, OS is pure overhead of real work Application programs have the real value to person who buys the computer

Perspectives of the Computerprint cut send save open() malloc() fork()

Slide 1-4

read-disk

start-printer track-mouse

Application Software System Software Hardware

Application Software System Software Hardware

Application Software System Software Hardware (c) OS Programmer View

(a) End User View

(b) Application Programmer View

2

System SoftwareIndependent of individual applications, but common to all of them ExamplesC library functions A window system A database management system Resource management functions The OS

Slide 1-5

Using the System SoftwareApplication Programmer

Slide 1-6

Software API System SoftwareCommand Line Interpreter Compiler Loader Libraries Libraries Libraries Window System

Database Management System

OS

Hardware

3

Application Software, System Software, and the OS

Slide 1-7

Human-Computer Interface Application Software API System Software (More Abstract Resources) OS Interface Trusted OS (Abstract Resources) Software-Hardware Interface Hardware Resources

The OS as Resource ManagerProcess: An executing program Resource: Anything that is needed for a process to runMemory Space on a disk The CPU

Slide 1-8

An OS creates resource abstractions An OS manages resource sharing

4

Resource Abstractionload(block, length, device); seek(device, 236); out(device, 9) write(char *block, int len, int device, int track, int sector) { ... load(block, length, device); seek(device, 236); out(device, 9); ... }

Slide 1-9

write(char *block, int len, int device,int addr); fprintf(fileID, %d, datum);

Disk AbstractionsApplication Programmer OS Programmer

Slide 1-10

load(); seek(); out();

void write() { load(); seek() out() }

int fprintf() { ... write() }

(a) Direct Control

(b) write() abstraction

(c) fprintf() abstraction

5

Abstract ResourcesUser Interface Application Abstract Resources (API) Middleware OS Resources (OS Interface) OS Hardware Resources

Slide 1-11

Abstract MachinesIdea Program Idea Program Abstract Machines Physical Machine

Slide 1-12

Result

Result

Idea

Program

Result

6

Resource Sharing Space- vs time-multiplexed sharing To control sharing, must be able to isolate resources OS usually provides mechanism to isolate, then selectively allows sharing How to isolate resources How to be sure that sharing is acceptable

Slide 1-13

Concurrency

The OS as a Conductor

Slide 1-14

The OS coordinates the sharing and use of all the components in the computer

7

MultiprogrammingAbstract Machine Pi Abstract Machine Pj Abstract Machine Pk

Slide 1-15

OS Resource Sharing

Pi Memory Pk Memory

Time-multiplexed Physical Processor

Pj Memory

Space-multiplexed Physical Memory

Slide 1-16

Multiprogramming(2) Technique for sharing the CPU among runnable processes Process may be blocked on I/O Process may be blocked waiting for other resource, including the CPU

While one process is blocked, another might be able to run Multiprogramming OS accomplishes CPU sharing automatically scheduling Reduces time to run all processes

8

How Multiprogramming WorksProcess 1 Process 2 Process 3

Slide 1-17

Time-multiplexed CPUProcess 4

Space-multiplexed Memory

Speeding Up the Car WashVacuum Inside Wash

Slide 1-18

Dry

(a) The Sequential Car Wash

Vacuum Inside Wash (b) The Parallel Car Wash Dry

9

Multiprogramming PerformancePis Total Execution Time, ti0 ti

Slide 1-19

Time

(a) Pis Use of Machine ResourcesP1 P2 Pi PN

Time

(a) All Processes Use of Machine ResourcesUsing the processor I/O operation

OS Strategies Batch processing Timesharing Personal computer & workstations Process control & real-time Network Distributed Small computers

Slide 1-20

10

Batch Processing

Slide 1-21

Job 19

Job 3

Input Spooler

Output Spooler

Input Spool

Output Spool

Batch Processing(2)

Slide 1-22

Uses multiprogramming Job (file of OS commands) prepared offline Batch of jobs given to OS at one time OS processes jobs one-after-the-other No human-computer interaction OS optimizes resource utilization Batch processing (as an option) still used today

11

A Shell Script Batch File

Slide 1-23

cc -g -c menu.c cc -g -o driver driver.c menu.o driver < test_data > test_out lpr -PthePrinter test_out tar cvf driver_test.tar menu.c driver.c test_data test_out uuencode driver_test.tar driver_test.tar >driver_test.encode

Timesharing SystemsAbstract Machines ResultCommand

Slide 1-24

Physical Machine

ResultCommand

ResultCommand

12

Timesharing Systems(2)Computer Research Corp 67

Slide 1-25

Uses multiprogramming Support interactive computing model (Illusion of multiple consoles) Different scheduling & memory allocation strategies than batch Tends to propagate processes Considerable attention to resource isolation (security & protection) Tend to optimize response time

Personal Computers CPU sharing among one persons processes Power of computing for personal tasks Graphics Multimedia

Slide 1-26

Trend toward very small OS OS focus on resource abstraction Rapidly evolved to personal multitasking systems

13

Process Control & Real-Time Computer is dedicated to a single purpose Classic embedded system Must respond to external stimuli in fixed time Continuous media popularizing real-time techniques An area of growing interest

Slide 1-27

Networks LAN (Local Area Network) evolution 3Mbps (1975) 10 Mbps (1980) 100 Mbps (1990) 1 Gbps (2000) High speed communication means new way to do computing Shared files Shared memory Shared procedures/objects ???

Slide 1-28

14

Distributed OS Wave of the futureApp App App App Distributed OS App App

Slide 1-29

Multiple Computers connected by a Network

Small Computers PDAs, STBs, embedded systems became commercially significant Have an OS, but Not general purpose Limited hardware resources Different kinds of devices Touch screen, no keyboard Graffiti

Slide 1-30

Evolving & leading to new class of Oses

PalmOS, Pocket PC (WinCE), VxWorks,

15

Evolution of Modern OSTimesharingMemory Mgmt Scheduling Batch Protection Memory Mgmt Protection Scheduling Files Devices

Slide 1-31

Network OS PC & WkstationSystem software Human-Computer Interface Client-Server Model Protocols

Real-TimeScheduling

Small Computer Modern OSNetwork storage, Resource management

Examples of Modern OS UNIX variants (e.g. Linux) -- have evolved since 1970 Windows NT/2K -- has evolved since 1989 (much more modern than UNIX Win2K = WinNT, V5

Slide 1-32

Research OSes still evolving Small computer OSes still evolving

16

The Microsoft OS FamilyWin32 API Win32 API Subset Win32 API SubSet Windows CE (Pocket PC) Windows 95/98/Me

Slide 1-33

Windows NT/2000/XP

SummaryAn Operating System must be able to: provide functionality to apps provide abstraction of hardware to users and apps provide the sharing of resources to processes provide security and protection be as transparent as possible be as light as possible

Slide 1-34

17

Slide 2-1

Using the Operating System

The Airplane Pilots Abstract Machine

Slide 2-2

1

Basic AbstractionsIdea Program Idea Program Abstract Machine Physical Machine Abstract Machine

Slide 2-3

Result

Result

Idea

Program

Abstract Machine

Abstract Machine Entities Process: A sequential program in execution Resource: Any abstract resource that a process can request, and which may can cause the process to be blocked if the resource is unavailable. File: A special case of a resource. A linearly-addressed sequence of bytes. A byte stream.

ResultSlide 2-4

2

Algorithms, Programs, and Processes IdeaExecution Engine

Slide 2-5

Algorithm

Status Stack

Files Files Files

Source Program

Binary Program

Data

Other Resources

Process

Classic Process

Slide 2-6

OS implements {abstract machine} one per task Multiprogramming enables N programs to be space-muxed in executable memory, and timemuxed across the physical machine processor. Result: Have an environment in which there can be multiple programs in execution concurrently*, each as a processes* Concurrently: Programs appear to execute simultaneously

3

Process Abstraction

Slide 2-7

Data Process Program Stack Executable Memory

Operating SystemProcessor

Hardware

Processes Sharing a ProgramP1 P2 P3Files Files

Slide 2-8

P1Files Files

P2Files Files

Shared Program Text

P3

4

Multithreaded Accountant

Slide 2-9

Invoice First Accountant Purchase Orders Invoice

Invoice Second Accountant

Accountant & Clone Purchase Orders

(a) Separate Processes

(b) Double Threaded Process

Modern Process & Thread Divide classic process:

Slide 2-10

Process is an infrastructure in which execution takes place address space + resources Thread is a program in execution within a process context each thread has its own stackStack Data Process ProgramThread Thread

Thread

Operating System

Stack

Stack

5

A Process with Multiple ThreadsThread (Execution Engine)Status Stack Status Stack Status Stack Files Files Files Data Binary Program Other Resources

Slide 2-11

Process

More on Processes Abstraction of processor resource Programmer sees an abstract machine environment with spectrum of resources and a set of resource addresses (most of the addresses are memory addresses) User perspective is that its program is the only one in execution OS perspective is that it runs one program with its resources for a while, then switches to a different process (context switching)

Slide 2-12

OS maintains A process descriptor data structure to implement the process abstraction Identity, owner, things it owns/accesses, etc. Tangible element of a process

Resource descriptors for each resource

6

Slide 2-13

Address Space Process must be able to reference every resource in its abstract machine Assign each unit of resource an address Most addresses are for memory locations Abstract device registers Mechanisms to manipulate resources

Addresses used by one process are inaccessible to other processes Say that each process has its own address space

Shared Address Space Classic processes sharing program shared address space support Thread model simplifies the problem All threads in a process implicitly use that processs address space , but no unrelated threads have access to the address space Now trivial for threads to share a program and data

Slide 2-14

If you want sharing, encode your work as threads in a process If you do not want sharing, place threads in separate processes

7

Process & Address Space

Slide 2-15

Code

Data Stack

Resources Resources Resources

Abstract Machine Environment

Address Space

Creating a Process Here is the classic model for creating processes:

Slide 2-16

FORK(label)- Create another process in the same address space beginning execution at instruction label QUIT()- Terminate the process. JOIN(count)- Merge processes into one. Equivalent Code:disableInterrupts(); count--; if(count > 0) QUIT(); enableInterrupts();

8

ExampleprocA() { while(TRUE) { ; update(x); ; retrieve(y); } }

Slide 2-17

procB() { while(TRUE) { retrieve(x); ; update(y); ; } }

x Process A y Process B

Example (cont)L0: count = 2;

9

Slide 2-19

Example (cont)L0: count = 2; ; B2>

L3:

UNIX Processes

Slide 2-20

Status

Stack Segment Data Segment

Files Files Files

Text Segment

Other Resources

ProcessUNIX Kernel

10

UNIX Processes Each process has its own address space Subdivided into text, data, & stack segment a.out file describes the address space

Slide 2-21

OS kernel creates descriptor to manage process Process identifier (PID): User handle for the process (descriptor) Try ps and ps -aux (read man page)

A Process with Multiple ThreadsThread (Execution Engine)Status Stack Status Stack Status Stack Files Files Files Data Binary Program Other Resources

Slide 2-22

Process

11

Creating/Destroying Processes UNIX fork() creates a process Creates a new address space Copies text, data, & stack into new address space Provides child with access to open files

Slide 2-23

UNIX wait() allows a parent to wait for a child to terminate UNIX execve() allows a child to run a new program

Creating a UNIX Process

Slide 2-24

int pidValue; ... pidValue = fork(); /* Creates a child process */ if(pidValue == 0) { /* pidValue is 0 for child, nonzero for parent */ /* The child executes this code concurrently with parent */ childsPlay(); /* A procedure linked into a.out */ exit(0); } /* The parent executes this code concurrently with child */ parentsWork(..); wait(); ...

12

Child Executes a Different Program

Slide 2-25

int pid; ... /* Set up the argv array for the child */ ... /* Create the child */ if((pid = fork()) == 0) { /* The child executes its own absolute program */ execve(childProgram.out, argv, 0); /* Only return from an execve call if it fails */ printf(Error in the exec terminating the child ); exit(0); } ... wait(); /* Parent waits for child to terminate */ ...

Example: Parent#include #define NULL 0

Slide 2-26

int main (void) { if (fork() == 0){ /* This is the child process */ execve("child",NULL,NULL); exit(0); /* Should never get here, terminate */ } /* Parent code here */ printf("Process[%d]: Parent in execution ...\n", getpid()); sleep(2); if(wait(NULL) > 0) /* Child terminating */ printf("Process[%d]: Parent detects terminating child \n", getpid()); printf("Process[%d]: Parent terminating ...\n", getpid()); }

13

Example: Child

Slide 2-27

int main (void) { /* The child process's new program This program replaces the parent's program */ printf("Process[%d]: child in execution ...\n", getpid()); sleep(1); printf("Process[%d]: child terminating ...\n", getpid()); }

Threads -- The NT ModelThread (Execution Engine)Status Stack Status Stack Status Stack Files Files Files Data Binary Program Other Resources

Slide 2-28

Process

14

Windows NT Process

Slide 2-29

#include ... int main(int argv, char *argv[]) { ... STARTUPINFO startInfo; PROCESS_INFORMATION processInfo; ... strcpy(lpCommandLine, C:\\WINNT\\SYSTEM32\\NOTEPAD.EXE temp.txt); ZeroMemory(&startInfo, sizeof(startInfo)); startInfo.cb = sizeof(startInfo); if(!CreateProcess(NULL, lpCommandLine, NULL, NULL, FALSE, HIGH_PRIORITY_CLASS | CREATE_NEW_CONSOLE, NULL, NULL, &startInfo, &processInfo)) { fprintf(stderr, CreateProcess failed on error %d\n, GetLastError()); ExitProcess(1); }; /* A new child process is now executing the lpCommandLine program */ ... CloseHandle(&processInfo.hThread); CloseHandle(&processInfo.hProcess); t_handle = CreateProcess(, lpCommandLine, ); }

NT Threads

Slide 2-30

#include ... int main(int argv, char *argv[]) { t_handle = CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, // pointer to thread security attributes DWORD dwStackSize, // initial thread stack size, in bytes LPTHREAD_START_ROUTINE lpStartAddress, // pointer to thread function LPVOID lpParameter, // argument for new thread DWORD dwCreationFlags, // creation flags LPDWORD lpThreadId // pointer to returned thread identifier ); /* A new child thread is now executing the tChild function */ Sleep(100) /* Let another thread execute */ } DWPRD WINAPI tChild(LPVOID me) { /* This function is executed by the child thread */ ... SLEEP(100); /* Let another thread execute */ ... }

15

_beginthreadex()Single copy of certain variables in a process Need a copy per thread

Slide 2-31

unsigned long _beginthreadex( void *security, unsigned stack_size, unsigned ( __stdcall *start_address )( void * ), void *arglist, unsigned initflag, unsigned *thrdaddr );

Resources Anything that a process requests from an OS Available allocated Not available process is blocked

Slide 2-32

Examples Files Primary memory address space (virtual memory) Actual primary memory (physical memory) Devices (e.g., window, mouse, kbd, serial port, ) Network port many others

16

Files Data must be read into (and out of) the machine I/O devices Storage devices provide persistent copy Need an abstraction to make I/O simple the file A file is a linearly-addressed sequence of bytes From/to an input device Including a storage device

Slide 2-33

The File AbstractionData Process Program Stack File

Slide 2-34

Operating SystemProcessor Executable Memory File Descriptor

Hardware

Storage Device

17

UNIX Files UNIX and NT try to make every resource (except CPU and RAM) look like a file Then can use a common interface:open close read write lseek ioctl Specifies file name to be used Release file descriptor Input a block of information Output a block of information Position file for read/write Device-specific operations

Slide 2-35

UNIX File Example#include #include int main() { int inFile, outFile; char *inFileName = in_test; char *outFileName = out_test; int len; char c; inFile = open(inFileName, O_RDONLY); outFile = open(outFileName, O_WRONLY); /* Loop through the input file */ while ((len = read(inFile, &c, 1)) > 0) write(outFile, &c, 1); /* Close files and quite */ close(inFile); close(outFile); }

Slide 2-36

18

Windows File Manipulation Program

Slide 2-37

#include #include #define BUFFER_LEN ... // # of bytes to read/write /* The producer process reads information from the file name in_test then writes it to the file named out_test. */ int main(int argc, char *argv[]) { // Local variables char buffer[BUFFER_LEN+1]; // CreateFile parameters DWORD dwShareMode = 0; // share mode LPSECURITY_ATTRIBUTES lpFileSecurityAttributes = NULL; // pointer to security attributes HANDLE hTemplateFile = NULL; // handle to file with attributes to copy // ReadFile parameters HANDLE sourceFile; // Source of pipeline DWORD numberOfBytesRead; // number of bytes read LPOVERLAPPED lpOverlapped = NULL; // Not used here

Windows File Manipulation Program(2)

Slide 2-38

// WriteFile parameters HANDLE sinkFile; // Source of pipeline DWORD numberOfBytesWritten; // # bytes written // Open the source file sourceFile = CreateFile ( "in_test", GENERIC_READ, dwShareMode, lpFileSecurityAttributes, OPEN_ALWAYS, FILE_ATTRIBUTE_READONLY, hTemplateFile ); if(sourceFile == INVALID_HANDLE_VALUE) { fprintf(stderr, "File open operation failed\n"); ExitProcess(1); }

19

Windows File Manipulation Program(3)

Slide 2-39

// Open the sink file sinkFile = CreateFile ( "out_test", GENERIC_WRITE, dwShareMode, lpSecurityAttributes, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, hTemplateFile ); if(sinkFile == INVALID_HANDLE_VALUE) { fprintf(stderr, "File open operation failed\n"); ExitProcess(1); }

Windows File Manipulation Program(4)

Slide 2-40

// Main loop to copy the file while ( ReadFile( sourceFile, buffer, BUFFER_LEN, &numberOfBytesRead, lpOverlapped ) && numberOfBytesRead > 0 ) { WriteFile(sinkFile, buffer, BUFFER_LEN, &numberOfBytesWritten, lpOverlapped); } // Terminating. Close the sink and source files CloseHandle(sourceFile); CloseHandle(sinkFile); ExitProcess(0);

}

20

Shell Command Line InterpreterInteractive UserApplication & System Software

Slide 2-41

Shell ProgramOS System Call Interface OS

The Shell Strategy% grep first f3 read keyboardShell Process

Slide 2-42

fork a process Process to execute command

f3

read file

21

Bootstrapping Computer starts, begins executing a bootstrap program -- initial process Loads OS from the disk (or other device) Initial process runs OS, creates other processes

Slide 2-43

Slide 2-44

Serial Port A Serial Port B Serial Port C

login login login

Serial Port Z

login

getty /etc/passwd

22

Objects A recent trend is to replace processes by objects Objects are autonomous Objects communicate with one another using messages Popular computing paradigm Too early to say how important it will be ...

Slide 2-45

23

Slide 3-1

Operating System Organization

Purpose of an OSProcesses Coordinate Use of the Abstractions The Abstractions

Slide 3-2

Create the Abstractions

1

OS Requirements Provide resource abstractions Process abstraction of CPU/memory use Address space Thread abstraction of CPU within address space

Slide 3-3

Resource abstraction Anything a process can request that can block the process if it is unavailable NT uses object abstraction to reference resources

File abstraction of secondary storage use

OS Requirements Device Management Process, thread, and resource management Memory Management File Management

Slide 3-4

2

Device ManagementDevice-Independent Part

Slide 3-5

Device-Dependent Part

Device-Dependent Part

Device-Dependent Part

Device

Device

Device

Virtual Device Driversused in virtualization environments

Slide 3-6

emulate a piece of hardware - illusion of accessing real hardware How does it work? Attempts by the guest operating system to access the hardware are routed to the virtual device driver in the host operating system as function calls

3

Process, Thread, and Resource ManagementProcess, thread, and resource manager Thread Abstraction Process Abstraction Other Generic Resource Manager

Slide 3-7

Multiprogramming

Primary Memory

Abstract Resources

Processor

Memory ManagementIsolation & Sharing

Slide 3-8

Process Manager

Block Allocation

Virtual Memory

Primary Memory

Storage Devices

4

File ManagementAbstraction of storage devices Interacts with device and memory managers Modern OS: file system can be distributed across a network of machines

Slide 3-9

Slide 3-10

OS Design Constraints Performance Protection and security Correctness Maintainability Commercial factors Standards and open systems

5

Two software design issues

Slide 3-11

Performance - OS must be efficient efficient use of resources (CPU time and memory space) Maximize the availability of resources Exclusive use of resources - OS must provide resource isolationOS Mechanisms to Handle Performance and Exclusive use of resources Processor Modes - hardware mode bit is used to distinguish between OS and user instructions Kernels - most critical part of OS placed in kernel (trusted software module) Method of invoking system service - calling a system function or sending a message to a system process

Performance The OS is an overhead function should not use too much of machines resources Minimum functionality is to implement abstractions Additional function must be traded off against performance DOS: one process UNIX: low level file system

Slide 3-12

6

Exclusive Access to a Resource Exclusive control of a resource - must be guaranteed OS provides mechanism to isolate processes OS must also provide ability for processes to share Security Policy - the machine specific strategy for managing access to resources Trusted software - carefully constructed and part of OS (us)Kernel

Slide 3-13

Untrusted software - temporary and unknown (them)Apps, system software, and OS extensions

Exclusive Access to a ResourceProcessor Process A Process B Supervisor Program

Slide 3-14

As Protected Object

7

Protection & Security

Slide 3-15

Multiprogramming resource sharing Therefore, need software-controlled resource isolation Security policy: Sharing strategy chosen by computers owner Protection mechanism: Tool to implement a family of security policies

Processor Modes Mode bit: Supervisor or User mode Supervisor mode Can execute all machine instructions Can reference all memory locations

Slide 3-16

User mode Can only execute a subset of instructions Can only reference a subset of memory locations

8

Kernels

Slide 3-17

The part of the OS critical to correct operation (trusted software) Executes in supervisor mode The trap instruction is used to switch from user to supervisor mode, entering the OS

Supervisor and User Memory

Slide 3-18

User Process Supervisor Process

User Space

Supervisor Space

9

Procedure Call and Message Passing Operating Systemssend(, A, ); receive(, B, );

Slide 3-19

call();

trap

send/receive

return;

receive(A, ); send(, B, );

System Call Using the trap Instruction fork(); fork() { trap N_SYS_FORK() }

Slide 3-20

Trap Table

Kernel

sys_fork()

sys_fork() { /* system function */ return; }

10

A Thread Performing a System CallUser Space Kernel Space

Slide 3-21

Thread fork();

sys_fork() { }

Correctness & Maintainability

Slide 3-22

Security depends on correct operation of software trusted vs untrusted software Maintainability relates to ability of software to be changed If either is sufficiently important, can limit the function of the OS Guiding a manned spaceship Managing a nuclear reactor

11

Basic Operating System OrganizationProcess, Thread & Resource Manager File Manager

Slide 3-23

Memory Manager

Device Manager

Processor(s)

Main Memory

Devices

Basic Operating System OrganizationDilemma - modularize vs. flater design Modularize Four separate functional units Easier to maintain and update Flater performance important UNIX - four parts combined into one

Slide 3-24

12

Basic Operating System OrganizationProcess, Thread & Resource Manager File Manager

Slide 3-25

Memory Manager

Device Manager

Processor(s)

Main Memory

Devices

MicroKernelMicroKernel - only essential trusted code thread scheduling hardware device management fundamental protection mechanisms other basic functions remainder of the 4 - into user code Must use system call to microkernel

Slide 3-26

13

Modern OS KernelsUnix - first to support multiprogramming and networking Windows version - more widely used

Slide 3-27

The UNIX ArchitectureInteractive User Application Programs OS System Call Interface Driver InterfaceTrap Table

Slide 3-28

Libraries

Commands

Device Driver Device Driver

Monolithic Kernel ModuleProcess Management Memory Management File Management Device Mgmt Infrastructure

Device Driver

14

Windows NT OrganizationT

Slide 3-29

ProcessT T T

T

ProcessT T T

LibrariesUser Supervisor

Subsystem

Process Management Memory Management File Management Subsystem Subsystem Device Mgmt Infrastructure

Process

T

NT Executive NT Kernel Hardware Abstraction LayerProcessor(s) Main Memory

I/O Subsystem

Devices

NT Design GoalsExtensibility configured for workstation or server OS uses the same source code in both extensible nucleus software model like microkernel Portability Reliability and Security

Slide 3-30

15

Windows NT OrganizationT

Slide 3-31

ProcessT T T

T

ProcessT T T

LibrariesUser Supervisor

Subsystem

Process Management Memory Management File Management Subsystem Subsystem Device Mgmt Infrastructure

Process

T

NT Executive NT Kernel Hardware Abstraction LayerProcessor(s) Main Memory

I/O Subsystem

Devices

Slide 3-32

DOS -- Resource Abstraction OnlyProgram Libraries Program Program

OS Services ROM RoutinesProcessor(s) Main Memory Devices

16

Abstraction & SharingProcess Program State Process Program State

Slide 3-33

Libraries

Process Program State

OS Services Abstraction Manage sharingProcessor(s) Main Memory

ROM RoutinesDevices

Slide 3-34

Microkernel OrganizationProcess LibrariesUser Supervisor

Process Process

Server

Server Microkernel

Server

Device Drivers

Processor(s)

Main Memory

Devices

17

Monitoring the KernelTask Manager pview pstatUser Supervisor T

Slide 3-35

ProcessT T T

T

ProcessT T T

Process

T

Libraries Subsystem Subsystem Subsystem

NT Executive NT Kernel Hardware Abstraction LayerProcessor(s) Main Memory

I/O Subsystem

Devices

18

Slide 4-1

Computer Organization

Stored Program Computers and Electronic DevicesPattern

Slide 4-2

Jacquard Loom

Variable Program

Stored Program Device Fixed Electronic Device

1

Program SpecificationSourceint . . a = d = a, b, c, d; . b + c; a - 100;

Slide 4-3

Assembly Language; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a ; Code for d = a - 100 load R4,=100 subtract R3,R4 store R3,d

Machine LanguageAssembly Language; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a ; Code for d = a - 100 load R4,=100 subtract R3,R4 store R3,d

Slide 4-4

Machine Language101110010011001 101110010100000 101001110011000 101110100011001 101110010100000 101001100011000 101110011011001

2

The von Neumann ArchitectureCentral Processing Unit (CPU)Arithmetical Logical Unit (ALU) Control Unit (CU)

Slide 4-5

Address Bus Data BusPrimary Memory Unit (Executable Memory)

Device

The ALURight Operand Left Operand R1 R2 ... Rn load load add store

Slide 4-6

R3,b R4,c R3,R4 R3,a

Functional UnitResult

Status Registers

To/from Primary Memory

3

Control Unitload load add store

Slide 4-7

R3,b R4,c R3,R4 R3,a

Fetch Unit

PCDecode Unit

3050 load R4, c

IRExecute Unit

3046 3050 3054 3058

101110010011001 101110010100000 101001110011000 101110100011001

Control Unit

Primary Memory

Control Unit Operation Fetch phase: Instruction retrieved from memory Execute phase: ALU op, memory data reference, I/O, etc.PC = ; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; // fetch phase };

Slide 4-8

4

Primary Memory UnitMAR MDR Command1234 98765 read 1234 98765 0 1 2

Slide 4-9

Read Op: 1. Load MAR with address 2. Load Command with read 3. Data will then appear in the MDR

n-1

The Device-Controller-Software RelationshipSoftware in the CPU Application Program Abstract I/O Machine

Slide 4-10

Device manager Program to manage device controller Supervisor mode software

Device Controller Device

5

Device Controller InterfaceBusy/done bits used to signal event occurrences to software and software to device... busy done Error code ...

Slide 4-11

busy done 0 0 idle 0 1 finished 1 0 working 1 1 (undefined)

Command

Status

Data 0 Data 1

LogicData n-1

Performing a Write Operationwhile(deviceNo.busy || deviceNo.done) ; deviceNo.data[0] = deviceNo.command = WRITE; while(deviceNo.busy) ; deviceNo.done = TRUE;

Slide 4-12

Devices much slower than CPU CPU waits while device operates Would like to multiplex CPU to a different process while I/O is in process

6

CPU-I/O OverlapReady Processes Ready Processes Ready Processes

Slide 4-13

CPU

CPU

CPU

Device

Device

Device

I/O Operation

Uses CPU

Slide 4-14

Determining When I/O is CompleteCPU

Interrupt Pending

Device

Device

Device

CPU incorporates an interrupt pending flag When device.busy FALSE, interrupt pending flag is set Hardware tells OS that the interrupt occurred Interrupt handler part of the OS makes process ready to run

7

Control Unit with Interrupt (Hardware)PC = ; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; if(InterruptRequest) { memory[0] = PC; PC = memory[1] };

Slide 4-15

memory[1] contains the address of the interrupt handler

Interrupt Handler (Software)

Slide 4-16

interruptHandler() { saveProcessorState(); for(i=0; ifire(); delete(thisEvent); }; }

33

Synchronization PrinciplesGordon College Stephen Brinton

The Problem with Concurrency Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes CONSUMER-PRODUCER problemin Producer count BUFFER out Consumer

1

Producer-ConsumerPRODUCER while (true) {/* produce an item and put in nextProduced

CONSUMER while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--;// consume the item in nextConsumered

while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; }

}

Race Condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with count = 5 initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4}

2

Solution to Critical Section1. Mutual Exclusion exclusive access to the critical section of the cooperating group.do { Entry section critical section Exit section remainder section } while (TRUE);

Solution to Critical Section (CS)1. Mutual Exclusion exclusive access to the critical section of the cooperating group. 2. Progress no process in CS then selection of process to enter CS cannot be postponed indefinitely

3

Solution to Critical Section1. Mutual Exclusion exclusive access to the critical section of the cooperating group. 2. Progress no process in CS then selection of process to enter CS cannot be postponed indefinitely 3. Bounded Waiting - There exists a bound (or limit) on the number of times other processes can enter CS after a process has made a request to enter and before it enters.

Petersons Solution: Algorithmic Model Two process solution Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted. The two processes share two variables: int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical section. The flag array: process is ready to enter the critical section. If (flag[i] == true) implies that process Pi is ready!

4

Petersons Solution: Process P1do { flag[i] = TRUE; turn = j; while ( flag[j] && turn == j); CRITICAL SECTION flag[i] = FALSE; REMAINDER SECTION } while (TRUE); Release Lock Acquire Lock

Synchronization Hardware Many systems provide hardware support for critical section code Uniprocessors could disable interrupts Currently running code would execute without preemption Generally too inefficient on multiprocessor systems (must tell all CPUs) Operating systems using this not broadly scalable Modern machines provide special atomic hardware instructions: Atomic = non-interruptable Two types: test memory word and set value swap contents of two memory words

5

TestAndndSet InstructionDefinition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: }

Solution Demo: TestAndndSet Instruction Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) Acquire Lock ; /* do nothing // critical section Release Lock

lock = FALSE; // remainder section

} while ( TRUE);

6

Solution Demo: TestAndndSet Instruction Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) Acquire Lock ; /* do nothing // critical section Release Lockboolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: }

lock = FALSE; // remainder section

} while ( TRUE);

Swap InstructionDefinition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: }

7

Solution Demo: Swap Instruction Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key. Solution: do { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section

lock = FALSE; // remainder section

} while ( TRUE);

Semaphore Does this require busy waiting? Semaphore S integer variable Two standard operations modify S: wait() and signal() Originally called P() and V() Less complicated Can only be accessed via two indivisible (atomic) operationswait (S) { while S value--; if (S->value < 0) { add this process to waiting queue (S->list) block(); } }

Implementation of signal:signal (semaphore *S) { S->value++; if (S->value list) wakeup(P); } }

10

Semaphore Implementation: no Busy waiting With each semaphore there is an associated waiting

queue. Each entry in a waiting queue has two data items:

value (of type integer) pointer to next record in the list

Two operations:

block place the process invoking the operation on the appropriate waiting queue.

wakeup remove one of processes in the waiting queue and place it in the ready queue.

Semaphore Implementation Must be executed atomically: no processes can execute

wait () and signal () on the same semaphore at the same time Thus, implementation becomes the critical section

problem where the wait and signal code are placed in the critical section. Could now have busy waiting in critical section implementationBut

implementation code is short busy waiting if critical section rarely occupied

Little

11

Deadlock and Starvation Deadlock two or more processes are waiting indenitely for an event that can be caused by only one of the waiting processes Let S and Q be two semaphores initialized to 1

P0 wait (S); wait (Q); . . signal (S); signal (Q); . .

P1 wait (Q); wait (S);

signal (Q); signal (S);

Starvation indenite blocking. A process may never be removed from the semaphore queue in which it is suspended.

Deadlock and Starvation Solution?What is a transaction? A transaction is a list of operations When the system begins to execute the list, it must execute all of them without interruption, or It must not execute any at all Example: List manipulator Add or delete an element from a list Adjust the list descriptor, e.g., length Too heavyweight need something simpler

12

Well-known Problems of SynchronizationBounded-Buffer Problem Readers and Writers Problem Dining-Philosophers Problem

Bounded-Buffer Problem N buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Semaphore empty initialized to the value N.

BUFFER

13

Bounded-Buffer Problem N buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Semaphore empty initialized to the value N.

BUFFER

Bounded Buffer Problem (Cont.) The structure of the producer process do { // produce an item wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (true);

14

Bounded Buffer Problem (Cont.) The structure of the consumer process do { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume the removed item } while (true);

Readers-Writers Problem A data set is shared among a number of concurrent processes Readers only read the data set; they do not perform any updates Writers can both read and write. Problem allow multiple readers to read at the same time. Only one single writer can access the shared data at the same time. Shared Data Data set Semaphore mutex initialized to 1. Semaphore wrt initialized to 1. Integer readcount initialized to 0.

15

Readers-Writers Problem (Cont.) The structure of a writer process do { wait (wrt) ; // writing is performed

signal (wrt) ; } while (true)

Readers-Writers Problem (Cont.) The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait (wrt) ; signal (mutex) // reading is performed wait (mutex) ; readcount - - ; if readcount == 0) signal (wrt) ; signal (mutex) ; } while (true)

16

Readers-Writers LocksGeneralized to provide reader-writer locks on some systems. Most useful in following situations: 1. In apps where it is easy to identify which processes only read shared data and which only write shared data. 2. In apps with more readers than writers. More overhead to create reader-writer lock than plain semaphores.

Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick[5] initialized to 1

17

Dining-Philosophers Problem (Cont.) The structure of Philosopher i :Do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (true) ;

Dining-Philosophers Problem (Cont.) The structure of Philosopher i :Do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat

DEADLOCK POSSIBLE

signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (true) ;

18

Problems with Semaphores Incorrect use of semaphore

operations: signal (mutex) . wait (mutex)No mutual exclusion

wait (mutex) wait (mutex)Deadlock

Omitting of wait (mutex) or signal (mutex) (or both)Either no mutual exclusion or deadlock

Monitors A high-level abstraction that provides a convenient and effective mechanism for process synchronization Only one process may be active within the monitor at a timemonitor monitor-name { // shared variable declarations procedure P1 () { . } procedure Pn () {} Initialization code ( .) { } } }

19

Schematic view of a Monitor

Condition Variables condition x, y; Two operations on a condition variable: x.wait () a process that invokes the operation is suspended. x.signal () resumes one of processes (if any) that invoked x.wait ()

20

Condition Variables If Q is signaled to continue then P must wait: Note: remember only one process in monitor at a time

Possible scenarios: Signal and wait: P waits for Q to leave or suspend Signal and continue: Q waits for P to leave or suspend

Monitor with Condition Variables

21

Solution to Dining Philosophersmonitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); }dp.pickup(i); Eat dp.putdown(i);

Solution to Dining Philosophers (cont)void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i].signal () ; } } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; } }

22

Java Monitors Every object in Java has associate with it a single lock A method declared synchronized means calling the method means capturing the lock for the object.public class SimpleClass { public synchronized void safeMethod() {

Java Monitors Every object in Java has associate with it a single lock A method declared synchronized means calling the method means capturing the lock for the object.public class SimpleClass { public synchronized void safeMethod() {

SimpleClass sc = new SimpleClass();

23

Synchronization Examples Windows XP Linux Pthreads

Windows XP Synchronization Uses interrupt masks to protect access to global resources on uniprocessor systems Uses spinlocks on multiprocessor systems Also provides dispatcher objects which may act as either mutexes and semaphores Dispatcher objects may also provide events An event acts much like a condition variable

24

Linux Synchronization Linux: disables interrupts to implement short critical sections

Linux provides: semaphores spin locks

Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables

Non-portable extensions include: read-write locks spin locks

25

Slide 8-1

Basic Synchronization Principles

Concurrency Value of concurrency speed & economics But few widely-accepted concurrent programming languages (Java, C# are exceptions) Few concurrent programming paradigm Each problem requires careful consideration There is no common model

Slide 8-2

OS tools to support concurrency tend to be low level

1

Command ExecutionEnter Loop Another Command? No Yes fork()code Enter Loop Another Command? No

Slide 8-3

Exit Loop Yes

Exit Loop

CreateProcess()code

Execute Command Wait for Child to Terminate

Execute Command

Execute Command

UNIX Shell

Windows Command Launch

Synchronizing Multiple Threads with a Shared VariableInitialize

Slide 8-4

CreateThread() Wait runTime seconds Thread Work

TRUE

TRUE

FALSE

FALSE

runFlag=FALSE Exit

Terminate

FALSE

runFlag?

TRUE

2

Traffic Intersections

Slide 8-5

Critical Sectionsshared double balance;

Slide 8-6

Code for p1. . . balance = balance + amount; amount; . . .

Code for p2. . . balance = balance . . .

balance+=amount balance

balance-=amount

3

Critical SectionsExecution of p1 load R1, balance load R2, amount Timer interrupt Execution of p2

Slide 8-7

Timer interrupt add R1, R2 store R1, balance

load load sub store

R1, R2, R1, R1,

balance amount R2 balance

Critical Sections Mutual exclusion: Only one process can be in the critical section at a time There is a race to execute critical sections (race condition) The sections may be defined by different code in different processes cannot easily detect with static analysis

Slide 8-8

Without mutual exclusion, results of multiple execution are not determinate Need an OS mechanism so programmer can resolve races

4

Slide 8-9

Critical Sections Mutual exclusion: Only one process can be in the critical section at a time There is a race to execute critical sections The sections may be defined by different code in different processes cannot easily detect with static analysis

Without mutual exclusion, results of multiple execution are not determinate Need an OS mechanism so programmer can resolve races

Some Possible Solutions Disable interrupts Software solution locks Transactions FORK(), JOIN(), and QUIT(

Slide 8-10

Terminate processes with QUIT() to synchronize Create processes whenever critical section is complete

something new

5

Slide 8-11

Disabling Interruptsshared double balance;

Code for p1

disableInterrupts(); balance = balance + amount; amount; enableInterrupts();

disableInterrupts(); balance = balance enableInterrupts();

Code for p2

Interrupts could be disabled arbitrarily long Really only want to prevent p1 and p2 from interfering with one another; this blocks all pi Try using a shared lock variable

Using a Lock Variableshared boolean lock = FALSE; shared double balance;

Slide 8-12

Code for p1

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE;

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /* Execute critical sect */ balance = balance - amount; /* Release lock */ lock = FALSE;

Code for p2

6

Busy Wait Conditionshared boolean lock = FALSE; shared double balance;

Slide 8-13

Code for p1

p1

lock = TRUE

Interrupt

lock = FALSE

p2

Interrupt

Blocked at while

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; / /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE;

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /* Execute critical sect */ balance = balance - amount; /* Release lock */ lock = FALSE;

Code for p2

Unsafe Solutionshared boolean lock = FALSE; shared double balance;

Interrupt

Slide 8-14

Code for p1

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE;

/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /* Execute critical sect */ balance = balance - amount; /* Release lock */ lock = FALSE;

Code for p2

Worse yet another race condition Is it possible to solve the problem?

7

Atomic Lock Manipulationenter(lock) { disableInterrupts(); /* Loop until lock is TRUE */ while(lock) { /* Let interrupts occur */ enableInterrupts(); disableInterrupts(); } lock = TRUE; enableInterrupts(); } exit(lock) { disableInterrupts(); lock = FALSE; enableInterrupts(); }

Slide 8-15

Bound the amount of time that interrupts are disabled Can include other code to check that it is OK to assign a lock but this is still overkill

Atomic Lock Manipulationshared int lock = FALSE; shared double amount,balance;

Slide 8-16

Code for p1

/* Acquire the lock */ enter(lock); /* Execute critical sect */ balance = balance + amount; /* Release lock */ exit(lock);

/* Acquire the lock */ enter(lock); /* Execute critical sect */ balance = balance - amount; /* Release lock */ exit(lock);

Code for p2

Bound the amount of time that interrupts are disabled Can include other code to check that it is OK to assign a lock but this is still overkill

8

Slide 8-17

Deadlocked Pirates

Deadlock (2)shared boolean lock1 = FALSE; shared boolean lock2 = FALSE; shared list L;

Slide 8-18

Code for p1

. . . /* Enter CS to delete elt */ enter(lock1); ; ; /* Enter CS to update len */ enter(lock2); ; /* Exit both CS */ exit(lock1); exit(lock2); . . .

. . . /* Enter CS to update len */ enter(lock2); ; /* Enter CS to add elt */ enter(lock1); ; /* Exit both CS */ exit(lock2); exit(lock1); . . .

Code for p2

9

Processing Two Componentsshared boolean lock1 = FALSE; shared boolean lock2 = FALSE; shared list L;

Slide 8-19

Code for p1

. . . /* Enter CS to delete elt */ enter(lock1); ; /* Exit CS */ exit(lock1); ; /* Enter CS to update len */ enter(lock2); ; /* Exit CS */ exit(lock2); . . .

. . . /* Enter CS to update len */ enter(lock2); ; /* Exit CS */ exit(lock2); /* Enter CS to add elt */ enter(lock1); ; /* Exit CS */ exit(lock1); . . .

Code for p2

Transactions A transaction is a list of operations When the system begins to execute the list, it must execute all of them without interruption, or It must not execute any at all

Slide 8-20

Example: List manipulator Add or delete an element from a list Adjust the list descriptor, e.g., length

Too heavyweight need something simpler

10

A Semaphore

Slide 8-21

Dijkstra Semaphore

Slide 8-22

Invented in the 1960s Conceptual OS mechanism, with no specific implementation defined (could be enter()/exit()) Basis of all contemporary OS synchronization mechanisms

11

Solution Constraints

Slide 8-23

Processes p0 & p1 enter critical sections Mutual exclusion: Only one process at a time in the CS Only processes competing for a CS are involved in resolving who enters the CS Once a process attempts to enter its CS, it cannot be postponed indefinitely After requesting entry, only a bounded number of other processes may enter before the requesting process

Notation Let fork(proc, N, arg1, arg2, , argN)be a command to create a process, and to have it execute using the given N arguments Canonical problem:Proc_0() { while(TRUE) { ; ; } } fork(proc_0, 0); fork(proc_1, 0);

Slide 8-24

proc_1() { while(TRUE { ; ; } }

12

Solution Assumptions Memory read/writes are indivisible (simultaneous attempts result in some arbitrary order of access) There is no priority among the processes Relative speeds of the processes/processors is unknown Processes are cyclic and sequential

Slide 8-25

Dijkstra Semaphore Definition

Slide 8-26

Classic paper describes several software attempts to solve the problem (see problem 4, Chapter 8) Found a software solution, but then proposed a simpler hardware-based solution A semaphore, s, is a nonnegative integer variable that can only be changed or tested by these two indivisible functions:V(s): [s = s + 1] P(s): [while(s == 0) {wait}; s = s - 1]

13

Solving the Canonical ProblemProc_0() { while(TRUE) { ; P(mutex); ; V(mutex); } } semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

Slide 8-27

proc_1() { while(TRUE { ; P(mutex); ; V(mutex); } }

Shared Account Balance ProblemProc_0() { . . . /* Enter the CS */ P(mutex); balance += amount; V(mutex); . . . } semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

Slide 8-28

proc_1() { . . . /* Enter the CS */ P(mutex); balance -= amount; V(mutex); . . . }

14

Sharing Two Variablesproc_A() { while(TRUE) { ; update(x); /* Signal proc_B */ V(s1); ; /* Wait for proc_B */ P(s2); retrieve(y); } } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0); fork(proc_B, 0);

Slide 8-29

proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); ; update(y); /* Signal proc_A */ V(s2); ; } }

Device Controller Synchronization

Slide 8-30

The semaphore principle is logically used with the busy and done flags in a controller Driver signals controller with a V(busy), then waits for completion with P(done) Controller waits for work with P(busy), then announces completion with V(done)

15

Bounded Buffer ProblemEmpty Pool

Slide 8-31

Producer

Consumer

Full Pool

Bounded Buffer Problem (2)

Slide 8-32

producer() { consumer() { buf_type *next, *here; buf_type *next, *here; while(TRUE) { while(TRUE) { produce_item(next); /* Claim full buffer */ /* Claim an empty */ P(mutex); P(empty); P(full); P(mutex); here = obtain(full); here = obtain(empty); V(mutex); V(mutex); copy_buffer(here, next); copy_buffer(next, here); P(mutex); P(mutex); release(here, emptyPool); release(here, fullPool); V(mutex); V(mutex); /* Signal an empty buffer */ /* Signal a full buffer */ V(empty); V(full); consume_item(next); } } } } semaphore mutex = 1; semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[N]; fork(producer, 0); fork(consumer, 0);

16

Bounded Buffer Problem (3)

Slide 8-33

producer() { consumer() { buf_type *next, *here; buf_type *next, *here; while(TRUE) { while(TRUE) { produce_item(next); /* Claim full buffer */ /* Claim an empty */ P(full); P(empty); P(mutex); P(mutex); here = obtain(full); here = obtain(empty); V(mutex); V(mutex); copy_buffer(here, next); copy_buffer(next, here); P(mutex); P(mutex); release(here, emptyPool); release(here, fullPool); V(mutex); V(mutex); /* Signal an empty buffer */ /* Signal a full buffer */ V(empty); V(full); consume_item(next); } } } } semaphore mutex = 1; semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[N]; fork(producer, 0); fork(consumer, 0);

Readers-Writers Problem

Slide 8-34

Writers Readers

17

Readers-Writers Problem (2)Writer Writer Writer Writer Writer Writer Writer

Slide 8-35

Reader Reader Reader Reader Reader Reader Reader Reader

Shared Resource

Readers-Writers Problem (3)Writer Writer Writer Writer Writer Writer Writer Reader Reader Reader Reader Reader Reader Reader Reader Shared Resource

Slide 8-36

18

Readers-Writers Problem (4)Reader Reader Reader Reader Reader Reader Reader Reader Writer Writer Writer Writer Writer Writer

Slide 8-37

Writer Shared Resource

First Solutionreader() { while(TRUE) { ; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); P(mutex); readCount--; if(readCount == 0) V(writeBlock); V(mutex); } } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0);

Slide 8-38

writer() { while(TRUE) { ; P(writeBlock); /* Critical section */ access(resource); V(writeBlock); } }

First reader competes with writers Last reader signals writers

19

First Solution (2)reader() { while(TRUE) { ; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); P(mutex); readCount--; if(readCount == 0) V(writeBlock); V(mutex); } } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0);

Slide 8-39

writer() { while(TRUE) { ; P(writeBlock); /* Critical section */ access(resource); V(writeBlock); } }

First reader competes with writers Last reader signals writers Any writer must wait for all readers Readers can starve writers Updates can be delayed forever May not be what we want

reader() { while(TRUE) { ;

Writer Precedence { writer()

Slide 8-40

4 2

1

P(readBlock); P(mutex1); readCount++; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); access(resource); P(mutex1); readCount--; if(readCount == 0) V(writeBlock); V(mutex1);

while(TRUE) { ; P(mutex2); writeCount++; if(writeCount == 1) P(readBlock); 3 V(mutex2); P(writeBlock); access(resource); V(writeBlock); P(mutex2) writeCount--; if(writeCount == 0) V(readBlock); V(mutex2); } }

} } int readCount = 0, writeCount = 0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer, 0);

20

Writer Precedence (2)

Slide 8-41

reader() { writer() { while(TRUE) { while(TRUE) { ; ; P(mutex2); 4 P(writePending); P(readBlock); writeCount++; P(mutex1); if(writeCount == 1) readCount++; P(readBlock); 3 if(readCount == 1) V(mutex2); 2 P(writeBlock); P(writeBlock); V(mutex1); access(resource); V(readBlock); V(writeBlock); 1 V(writePending); P(mutex2) access(resource); writeCount--; P(mutex1); if(writeCount == 0) readCount--; V(readBlock); if(readCount == 0) V(mutex2); V(writeBlock); } V(mutex1); } } } int readCount = 0, writeCount = 0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer, 0);

The Sleepy Barber Barber can cut one persons hair at a time Other customers wait in a waiting roomEntrance to Waiting Room (sliding door) Shop Exit Entrance to Barbers Room (sliding door)

Slide 8-42

Waiting Room

21

Sleepy Barber (aka Bounded Buffer)customer() { while(TRUE) { customer = nextCustomer(); if(emptyChairs == 0) continue; P(chair); P(mutex); emptyChairs--; takeChair(customer); V(mutex); V(waitingCustomer); } }

Slide 8-43

barber() { while(TRUE) { P(waitingCustomer); P(mutex); emptyChairs++; takeCustomer(); V(mutex); V(chair); } }

semaphore mutex = 1, chair = N, waitingCustomer = 0; int emptyChairs = N; fork(customer, 0); fork(barber, 0);

Cigarette Smokers Problem Three smokers (processes) Each wish to use tobacco, papers, & matches Only need the three resources periodically Must have all at once

Slide 8-44

3 processes sharing 3 resources Solvable, but difficult

22

Implementing Semaphores

Slide 8-45

Minimize effect on the I/O system Processes are only blocked on their own critical sections (not critical sections that they should not care about) If disabling interrupts, be sure to bound the time they are disabled

Implementing Semaphores: enter() & exit()class semaphore { int value; public: semaphore(int v = 1) { value = v;}; P(){ disableInterrupts(); while(value == 0) { enableInterrupts(); disableInterrupts(); } value--; enableInterrupts(); }; V(){ disableInterrupts(); value++; enableInterrupts(); }; };

Slide 8-46

23

Implementing Semaphores: Test and Set InstructionData CC Register Register Data CC Register Register

Slide 8-47

TS(m): [Reg_i = memory[m]; memory[m] = TRUE;]

R3

R3

FALSE

=0

m

FALSE

m

TRUE

Primary Memory

Primary Memory

(a) Before Executing TS

(b) After Executing TS

Using the TS Instruction

Slide 8-48

boolean s = FALSE; . . . while(TS(s)) ; s = FALSE; . . .

semaphore s = 1; . . . P(s) ; V(s); . . .

24

Implementing the General Semaphorestruct semaphore { int value = ; boolean mutex = FALSE; boolean hold = TRUE; }; shared struct semaphore s; P(struct semaphore s) { while(TS(s.mutex)) ; s.value--; if(s.value < 0) ( s.mutex = FALSE; while(TS(s.hold)) ; } else s.mutex = FALSE; }

Slide 8-49

V(struct semaphore s) { while(TS(s.mutex)) ; s.value++; if(s.value =1)&& &&(S[N-1]>=1)) { for(i=0; i0) { goto L1; R_num--; } else { dequeue(R_wait); // Release a thread S_num++; enqueue(CallingThread, S_wait); } if(S_num>0) { V(mutex); S_num--; goto L1; dequeue(S_wait); // Release a thread } } } V(mutex); } }

7

Slide 9-15

Dining Philosophers Problemphilosopher(int i) { while(TRUE) { // Think // Eat Psim(fork[i], fork [(i+1) mod 5]); eat(); Vsim(fork[i], fork [(i+1) mod 5]); } } semaphore fork[5] = (1,1,1,1,1); fork(philosopher, 1, 0); fork(philosopher, 1, 1); fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher, 1, 4);

Events

Slide 9-16

Exact definition is specific to each OS A process can wait on an event until another process signals the event Have event descriptor (event control block) Active approach Multiple processes can wait on an event Exactly one process is unblocked when a signal occurs A signal with no waiting process is ignored

May have a queue function that returns number of processes waiting on the event

8

Exampleclass Event { public: void signal(); void wait() int queue(); }

Slide 9-17

wait()

1

shared Event topOfHour; . . . // Wait until the top of the hour before proceding topOfHour.wait(); // Its the top of the hour ...

ResumetopOfHour

3

2signal()

shared Event topOfHour; . . . while(TRUE) if(isTopOfHour()) while(topOfHour.queue() > 0) topOfHour.signal(); } . . .

UNIX Signals A UNIX signal corresponds to an event

Slide 9-18

It is raised by one process (or hardware) to call another processs attention to an event It can be caught (or ignored) by the subject process

Justification for including signals was for the OS to inform a user process of an event User pressed delete key Program tried to divide by zero Attempt to write to a nonexistent pipe etc.

9

More on Signals Each version of UNIX has a fixed set of signals (Linux has 31 of them) signal.h defines the signals in the OS App programs can use SIGUSR1 & SIGUSR2 for arbitrary signalling Raise a signal with kill(pid, signal) Process can let default handler catch the signal, catch the signal with own code, or cause it to be ignored

Slide 9-19

More on Signals (cont) OS signal system call

Slide 9-20

To ignore: signal(SIG#, SIG_IGN) To reinstate default: signal(SIG#, SIG_DFL) To catch: signal(SIG#, myHandler)

Provides a facility for writing your own event handlers in the style of interrupt handlers

10

Slide 9-21

Signal Handling/* code for process p */ . . . signal(SIG#, myHndlr); . . . /* ARBITRARY CODE */ void myHndlr(...) { /* ARBITRARY CODE */ }

Signal Handling/* code for process p */ . . . signal(SIG#, sig_hndlr); . . . /* ARBITRARY CODE */

Slide 9-22

void sig_hndlr(...) { /* ARBITRARY CODE */ }

An executing process, q Raise SIG# for p q is blocked q resumes executionsig_hndlr runs in

ps address space

11

Using UNIX SignalsPis Address Space Pis Execution

Slide 9-23

Pjs Execution

program Pis Signal Handler signal hndlr data stack & heap

Toy Signal Handler

Slide 9-24

#include static void sig_handler(int); int main () { int i, parent_pid, child_pid, status; if(signal(SIGUSR1, sig_handler) == SIG_ERR) printf(Parent: Unable to create handler for SIGUSR1\n); if(signal(SIGUSR2, sig_handler) == SIG_ERR) printf(Parent: Unable to create handler for SIGUSR2\n); parent_pid = getpid(); if((child_pid = fork()) == 0) { kill(parent_pid, SIGUSR1); for (;;) pause(); } else { kill(child_pid, SIGUSR2); printf(Parent: Terminating child \n); kill(child_pid), SIGTERM); wait(&status); printf(done\n); } }

12

Toy Signal Handler (2)static void sig_handler(int signo) { switch(signo) { case SIGUSR1: /* Incoming SIGUSR1 */ printf(Parent: Received SIGUSER1\n); break; case SIGUSR2: /* Incoming SIGUSR2 */ printf(Child: Received SIGUSER2\n); break; default: break; } return }

Slide 9-25

Monitors Specialized form of ADT Encapsulates implementation Public interface (types & functions)

Slide 9-26

Only one process can be executing in the ADT at a time monitor anADT {semaphore mutex . . . public: proc_i() { P(mutex); // ; Implicit

13

Example: Shared Balancemonitor sharedBalance { double balance; public: credit(double amount) {balance += amount;}; debit(double amount) {balance -= amount;}; . . . };

Slide 9-27

Example: Readers & Writers

Slide 9-28

monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startRead() { reader(){ writer(){ }; while(TRUE) { while(TRUE) { finishRead() { . . . . . . }; startRead(); startWriter(); startWrite() { finishRead(); finishWriter(); }; . . . . . . finishWrite() { } } }; fork(reader, 0); }; . . . fork(reader, 0): fork(writer, 0); . . . fork(writer, 0);

14

Example: Readers & Writers

Slide 9-29

monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startWrite() { startRead() { numberOfWriters++; while(numberOfWriters != 0) ; while( numberOfReaders++; busy || }; (numberOfReaders > 0) finishRead() { ) ; numberOfReaders-; busy = TRUE; }; }; finishWrite() { numberOfWriters--; busy = FALSE; }; };

Slide 9-30

Example: Readers & Writersmonitor readerWriter_1 { Deadlock can happen int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startWrite() { startRead() { numberOfWriters++; while(numberOfWriters != 0) ; while( numberOfReaders++; busy || }; (numberOfReaders > 0) finishRead() { ) ; numberOfReaders--; busy = TRUE; }; }; finishWrite() { numberOfWriters--; busy = FALSE; }; };

15

Sometimes Need to Suspend Process obtains monitor, but detects a condition for which it needs to wait Want special mechanism to suspend until condition is met, then resume Process that makes condition true must exit monitor Suspended process then resumes

Slide 9-31

Condition Variable

Condition Variables

Slide 9-32

Essentially an event (as defined previously) Occurs only inside a monitor Operations to manipulate condition variable wait: Suspend invoking process until another

executes a signal signal: Resume one process if any are suspended, otherwise do nothing queue: Return TRUE if there is at least one process suspended on the condition variable

16

Active vs Passive signal p0 executes signal while p1 is waiting p0 yields the monitor to p1 The signal is only TRUE the instant it happens

Slide 9-33

Hoare semantics: same as active semaphore

Brinch Hansen (Mesa) semantics: same as passive semaphore p0 executes signal while p1 is waiting p0 continues to execute, then when p0 exits the monitor p1 can receive the signal Used in the Xerox Mesa implementation

Hoare vs Mesa Semantics Hoare semantics:

Slide 9-34

. . . if(resourceNotAvailable()) resourceCondition.wait(); /* now available continue */ . . .

Mesa semantics:. . . while(resourceNotAvailable()) resourceCondition.wait(); /* now available continue */ . . .

17

2nd Try at Readers & Writers

Slide 9-35

monitor readerWriter_2 { int numberOfReaders = 0; boolean busy = FALSE; condition okToRead, okToWrite; public: startWrite() { startRead() { if(busy || (okToWrite.queue()) if((numberOfReaders != 0) || busy) okToRead.wait(); okToWrite.wait(); numberOfReaders++; busy = TRUE; okToRead.signal(); }; }; finishWrite() { finishRead() { busy = FALSE; numberOfReaders--; if(okToRead.queue()) if(numberOfReaders == 0) okToRead.signal() okToWrite.signal(); else }; okToWrite.signal() }; };

Example: Synchronizing Traffic One-way tunnel Can only use tunnel if no oncoming traffic OK to use tunnel if traffic is already flowing the right way

Slide 9-36

18

Example: Synchronizing Traffic

Slide 9-37

monitor tunnel { int northbound = 0, southbound = 0; trafficSignal nbSignal = RED, sbSignal = GREEN; condition busy; public: nbArrival() { if(southbound > 0) busy.wait(); northbound++; nbSignal = GREEN; sbSignal = RED; }; sbArrival() { if(northbound > 0) busy.wait(); southbound++; nbSignal = RED; sbSignal = GREEN; }; depart(Direction exit) ( if(exit = NORTH { northbound--; if(northbound == 0) while(busy.queue()) busy.signal(); else if(exit == SOUTH) { southbound--; if(southbound == 0) while(busy.queue()) busy.signal(); } } }

Dining Philosophers again ...#define N ___ enum status(EATING, HUNGRY, THINKING}; monitor diningPhilosophers { status state[N]; condition self[N]; test(int i) { if((state[(i-1) mod N] != EATING) && (state[i] == HUNGRY) && (state[(i+1) mod N] != EATING)) { state[i] = EATING; self[i].signal(); } }; public: diningPhilosophers() { // Initilization for(int i = 0; i < N; i++) state[i] = THINKING; };

Slide 9-38

19

Dining Philosophers again ...test(int i) { if((state[(i-1) mod N] != EATING) && (state[i] == HUNGRY) && (state[(i+1) mod N] != EATING)) { state[i] = EATING; self[i].signal(); }; }; public: diningPhilosophers() {...}; pickUpForks(int i) { state[i] = HUNGRY; test(i); if(state[i] != EATING) self[i].wait(); }; putDownForks(int i) { state[i] = THINKING; test((i-1) mod N); test((i+1) mod N); }; }

Slide 9-39

Experience with Monitors Danger of deadlock with nested calls Monitors were implemented in Mesa Used Brinch Hansen semantics Nested monitor calls are, in fact, a problem Difficult to get the right behavior with these semantics Needed timeouts, aborts, etc.

Slide 9-40

20

Interprocess Communication (IPC) Different processes - no shared memory space IPC - a way for different processes to communicate even if they exist on different machines OS copies info from sending process memory space to receiving process memory space

Slide 9-41

IPC MechanismsMessage OS IPC Mechanism

Slide 9-42

Info copy

Info to be shared Address Space for p0

Address Space for p1

Must bypass memory protection mechanism for local copies Must be able to use a network for remote copies

21

Refined IPC Mechanism Spontaneous changes to p1s address space Avoid through the use of mailboxesAddress Space for p0 Mailbox for p1 Info to be sharedsend( p1, );

Slide 9-43

Address Space for p1

Message Message Message

Info copyreceive();

OS Interfacesend function receive function

Slide 9-44

OS manages the mailbox space More secure message systemAddress Space for p0 Info to be sharedsend( p1, );

Refined IPC MechanismAddress Space for p1 Info copy OS Interface Mailbox for p1receive();

send function

Message Message Message

receive function

22

Interprocess Communication (IPC)

Slide 9-45

Signals, semaphores, etc. do not pass information from one process to another Monitors support information sharing, but only through shared memory in the monitor There may be no shared memory OS does not support it Processes are on different machines on a network

Can use messages to pass info while synchronizing

Message Protocols Sender transmits a set of bits to receiver

Slide 9-46

How does the sender know when the receiver is ready (or when the receiver obtained the info)? How does the receiver know how to interpret the info? Need a protocol for communication Standard envelope for containing the info Standard header

A message system specifies the protocols

23

Transmit Operations Asynchronous send:

Slide 9-47

Delivers message to receivers mailbox Continues execution No feedback on when (or if) info was delivered

Synchronous send: Goal is to block sender until message is received by a process Variant sometimes used in networks: Until the message is in the mailbox

Receive Operation Blocking receive: Return the first message in the mailbox If there is no message in mailbox, block the receiver until one arrives

Slide 9-48

Nonblocking receive: Return the first message in the mailbox If there is no message in mailbox, return with an indication to that effect

24

Synchronized IPCCode for p1/* signal p2 */ syncSend(message1, p2); ; /* wait for signal from p2 */ blockReceive(msgBuff, &from);

Slide 9-49

Code for p2/* wait for signal from p1 */ blockReceive(msgBuff, &from); ; /* signal p1 */ syncSend(message2, p1);

syncSend()

blockReceive()

blockReceive()

syncSend()

Slide 9-50

Asynchronous IPCCode for p1 Code for p2/* signal p2 */ /* test for signal from p1 */ asyncSend(message1, p2); if(nbReceive(&msg, &from)) { ; ; /* wait for signal from p2 */ asyncSend(message2, p1); while(!nbReceive(&msg, &from)); }else< ; }nonblockReceive() asyncSend() nonblockReceive() nonblockReceive() asyncSend() nonblockReceive()

25

UNIX Pipes

Slide 9-51

Address Space for p1 Info to be sharedwrite(pipe[1], );

Info copy System Call Interface pipe for p1 and p2read(pipe[0]);

write function

read function

UNIX Pipes (cont) The pipe interface is intended to look like a file interface Analog of open is to create the pipe File read/write system calls are used to send/receive information on the pipe

Slide 9-52

What is going on here? Kernel creates a buffer when pipe is created Processes can read/write into/out of their address spaces from/to the buffer Processes just need a handle to the buffer

26

File handles are copied on fork so are pipe handles

UNIX Pipes (cont)

Slide 9-53

int pipeID[2]; . . . pipe(pipeID); . . . if(fork() == 0) { /* the child */ . . . read(pipeID[0], childBuf, len); ; . . . } else { /* the parent */ . . . write(pipeID[1], msgToChild, len); . . . }

The normal write is an asynchronous op (that notifies of write errors) The normal read is a blocking read The read operation can be nonblocking#include . . . int pipeID[2]; . . . pipe(pipeID); ioctl(pipeID[0], FIONBIO, &on); . . . read(pipeID[0], buffer, len); if(errno != EWOULDBLOCK) { /* no data */ } else { /* have data */

UNIX Pipes (cont)

Slide 9-54

27

Source, Filter and Sink Processes

Slide 9-55

Source

Filter

Sink

Information Flow Through UNIX Pipes

Slide 9-56

Address Space for p1 Info to be sharedwrite(pipe[1], );

Info copy System Call Interface pipe for p1 and p2read(pipe[0]);

write function

read function

28

DeadlocksGordon College Stephen Brinton

Deadlock Overview The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks

Deadlock Prevention Deadlock Avoidance Deadlock Detection Recovery from DeadlockObjectives To develop a description of deadlocks (prevent sets of concurrent processes from completing their tasks) To present a number of different methods for preventing or avoiding deadlocks in a computer system.

1

The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. Example System has 2 tape drives. P1 and P2 each hold one tape drive and each needs another one. Example semaphores A and B, initialized to 1P0 wait (A); wait (B); P1 wait(B) wait(A)

Bridge Crossing Example

Traffic only in one direction. Each section of a bridge can be viewed as a resource. If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). Several cars may have to be backed up if a deadlock occurs. Starvation is possible.

2

System Model Resource types R1, R2, . . ., RmCPU cycles, memory space, I/O devices

Each resource type Ri has Wi instances. Each process utilizes a resource as follows: request use release

Deadlock CharacterizationDeadlock can arise if four conditions hold simultaneously.

1. Mutual exclusion: only one process at a timecan use a resource.

2. Hold and wait: a process holding at least one 3. No preemption: a resource can be released

resource is waiting to acquire additional resources held by other processes. only voluntarily by the process holding it, after that process has completed its task. of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, , Pn1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0.

4. Circular wait: there exists a set {P0, P1, , P0}

3

Resource-Allocation GraphA set of vertices V and a set of edges E.

V is partitioned into two types: P = {P1, P2, , Pn}, the set consisting of all the processes in the system. R = {R1, R2, , Rm}, the set consisting of all resource types in the system. request edge directed edge P1 Rj

assignment edge

directed edge Rj Pi

Resource-Allocation Graph (Cont.) Process Resource Type with 4 instances

Pi requests instance of Rj

PiRj

Pi is holding an instance of Rj

PiRj

4

Resource Allocation Graph 1

Is there a deadlock in this graph?

Resource Allocation Graph 2

Is there a deadlock in this graph?

5

Resource Allocation Graph 3

Is there a deadlock in this graph?

Basic Facts If graph contains no cycles no deadlock. If graph contains a cycle if only one instance per resource type, then deadlock. if several instances per resource type, possibility of deadlock.

6

Methods for Handling Deadlocks1. Ensure that the system will never enter a deadlock state. 2. Allow the system to enter a deadlock state and then recover. 3. Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX and Windows.

Deadlock PreventionRestrain the ways request can be made.

Mutual Exclusion not required for

sharable resources; must hold for nonsharable resources. Hold and Wait must guarantee that whenever a process requests a resource, it does not hold any other resources. Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none. Low resource utilization; starvation possible.

7

Deadlock Prevention (Cont.) No Preemption If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released. Preempted resources are added to the list of resources for which the process is waiting. Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting.

Circular Wait impose a total ordering of

all resource types, and require that each process requests resources in an increasing order of enumeration.

Deadlock AvoidanceSome additional information must be available:

Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. The deadlock-avoidance algorithm dynamically examines the resourceallocation state to ensure that there can never be a circular-wait condition. Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

8

Safe State When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state. System is in safe state if there exists a safe sequence of all processes. Sequence is safe if for each Pi, the resources that Pi can still request can be satisfied by currently available resources + resources held by all the Pj, with j satisfies safety criteria.

14

Example P1 Request (1,0,2) (Cont.) Check that Request Available (that is, (1,0,2) (3,3,2) true. Allocation Need Available ABC ABC ABC Pretending P0 0 1 0 743 230 This Request P1 3 0 2 020 Has P2 3 0 1 600 Been Fullled P3 2 1 1 011 P4 0 0 2 431 Executing safety algorithm shows that sequence satisfies safety requirement. Can request for (3,3,0) by P4 be granted? Can request for (0,2,0) by P0 be granted?

Practice Question

Answer the following questions using the bankers algorithm:

a. What is the content of the matrix Need? b. Is the system in a safe state? c. If a request from process P1 arrives for (0,4,2,0), can the request be granted immediately?

15

Practice Question

a. What is the content of the matrix Need? The values of Need for processes P0 through P4 respectively are (0, 0, 0, 0), (0, 7, 5, 0), (1,0, 0, 2), (0, 0, 2, 0), and (0, 6, 4, 2). b. Is the system in a safe state? Yes. With Available being equal to (1,5, 2, 0), either process P0 or P3 could run. Once process P3 runs, it releases its resources which allow all other existing processes to run. c. If a request from process P1 arrives for (0,4,2,0), can the request be granted immediately? Yes it can. This results in the value of Available being (1, 1, 0, 0).One ordering of processes that can finish is P0, P2, P3, P1, and P4.

Deadlock Detection Allow system to enter deadlock state Detection algorithm Recovery scheme Overhead: algorithm and recovery

16

Single Instance of Each Resource Type Maintain wait-for graph Nodes are processes. Pi Pj if Pi is waiting for Pj.

Periodically invoke an algorithm that searches for a cycle in the graph. An algorithm to detect a cycle in a graph requires an order of n2 operations, where n is the number of vertices in the graph.

Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph

Corresponding wait-for graph

17

Several Instances of a Resource Type Available: A vector of length m indicates the number of available resources of each type. Allocation: An n x m matrix defines the number of resources of each type currently allocated to each process. Request: An n x m matrix indicates the current request of each process. If Request [ij] = k, then process Pi is requesting k more instances of resource type. Rj.

Detection Algorithm1. Let Work and Finish be vectors of length m and n, respectively Initialize:(a) Work = Available (b)For i = 1,2, , n, if Allocationi 0, then Finish[i] = false;otherwise, Finish[i] = true.

2. Find an index i such that both:(a)Finish[i] == false (b)Requesti Work If no such i exists, go to step 4.

18

Detection Algorithm (Cont.)3.Work = Work + Allocationi Finish[i] = true go to step 2. 4.If Finish[i] == false, for some i, 1 i n, then the system is in deadlock state. Moreover, if Finish[i] == false, then Pi is deadlocked.Algorithm requires an order of O(m x n2) operations to detect whether the system is in deadlocked state.

Example of Detection Algorithm Five processes P0 through P4; three resource types A (7 instances), B (2 instances), and C (6 instances). Snapshot at time T0: AllocationRequest Available ABC ABC ABC P0 0 1 0 000 000 P1 2 0 0 202 P2 3 0 3 000 P3 2 1 1 100 P4 0 0 2 002 Sequence will result in Finish[i] = true for all i.

19

Example (Cont.) P2 requests an additional instance of type C. Request ABC P0 0 0 0 P1 2 0 1 P2 0 0 1 P3 1 0 0 P4 0 0 2 State of system? Can reclaim resources held by process P0, but insufficient resources to fulfill other processes; requests. Deadlock exists, consisting of processes P1, P2, P3, and P4.

Detection-Algorithm Usage When, and how often, to invoke depends on: How often a deadlock is likely to occur? How many processes will need to be rolled back? one for each disjoint cycle If detection algorithm is invoked arbitrarily, there may be many cycles in the resource graph and so we would not be able to tell which of the many deadlocked processes caused the deadlock.

20

Recovery from Deadlock: Process Termination Terminate a process: Abort all deadlocked processes. Abort one process at a time until the deadlock cycle is eliminated. (overhead) In which order should we choose to abort? Priority of the process. How long process has computed, and how much longer to completion. Resources the process has used. Resources process needs to complete. How many processes will need to be terminated. Is process interactive or batch?

Recovery from Deadlock: Resource Preemption Selecting a victim minimize cost. Rollback return to some safe state, restart process for that state. Starvation same process may always be picked as victim, include number of rollback in cost factor.

21

Memory ManagementGordon College Stephen Brinton

Memory Management Background Swapping Contiguous Allocation Paging Segmentation Segmentation with Paging

1

Background Program must be brought into memory and placed within a process for it to be run hardware needs: - speed differential (cache) - separate memory spaces (base and limit register) Base Register: 34000 Limit Register: 12000 Address being used by a program must fall within this range or a trap (error) will result.

HW: address protection with base and limit registers

2

Address Binding Input queue collection of processes on the disk that are waiting to be brought into memory to run the program Binding symbolic addresses in a source program are bound to actually memory addresses.

Binding of Instructions and Data to MemoryAddress binding of