Outline Please turn in your homework #3 now • Announcements • Midterm Review

advertisement
Outline
• Announcements
• Midterm Review
Please turn in your homework #3 now
Announcements
• The midterm will be Oct. 23, 2003
– Please come to class as early as you can
– We will start when most of you have showed up
• If you cannot take the midterm this Thursday
– You need to have a legally valid reason
– You need to let me know as early as you can but
definitely before this Thursday so that we can
make arrangements
5/29/2016
COP4610
2
Announcements – cont.
• The midterm will be close-book and closenote
– However, a letter-size sheet is allowed
– You may need a calculator to perform certain
calculations
• Recitation session tomorrow
– It is optional
– I will be answering questions mainly
5/29/2016
COP4610
3
Announcements – cont.
• About Lab2
– The best type of semaphores for the lab is to use
sema_t
– The functions are sema_init, sema_wait,
sema_post, and sema_destroy (they are only
available on program)
– Some of you want to postpone the due date to
Nov. 4 instead of Oct. 30 due to midterms
• Let’s have a poll now
5/29/2016
COP4610
4
System Overview
• A computer system consists of hardware and
software that are combined to provide a tool
to solve specific problems
– Hardware includes CPU, memory, disks, printers,
screen, keyboard, mouse ...
– Software includes
• System software
– A general environment to create specific applications
• Application software
– A tool to solve a specific problem
5/29/2016
COP4610
5
System Overview
5/29/2016
COP4610
6
What is an Operating System?
• The operating system is the part of the
system software that manages the use of the
hardware used by other system software and
all application software
– It is the system program that acts between the
hardware and the user programs
5/29/2016
COP4610
7
What is an Operating System? - continued
• It provides services to user programs
– Through system calls / message passing
• File system services
• Memory services
• I/O services
• It hides hardware from user programs
– When your program shows a message on the monitor, it
does not need to know the details
– When your program generates a new file, it does not need
to where the free space is on your hard drive
5/29/2016
COP4610
8
Differences between OS and System Software
• Major differences between OS and general
system software
– General system software relies on the
abstractions provided by OS
– OS abstracts the hardware directly
– OS provides the fundamental trusted mechanisms
for resource sharing
– A general purpose OS is domain-independent
5/29/2016
COP4610
9
Operating System Functions
• Resource manager
– manage hardware and software resources
– Resource abstraction and sharing
• A nicer environment
– implement a virtual machine for processes to run in
• A program in execution is called a process
– a nicer environment than the bare hardware
5/29/2016
COP4610
10
Resource Management Functions
• Transform physical resources to logical
resources
– Resource abstraction
• Make the hardware resources easier to use
• Multiplex one physical resource to several
logical resources
– Create multiple, logical copies of resources
• Schedule physical and logical resources
– Decide who gets to use the resources
5/29/2016
COP4610
11
Resource Sharing
• Two types of sharing
– Time multiplexed sharing
• time-sharing
• schedule a serially-reusable resource among several
users
– Space multiplexed sharing
• space-sharing
• divide a multiple-use resource up among several users
5/29/2016
COP4610
12
Time-multiplexing the Processor
- Called multiprogramming, resulting in concurrency
5/29/2016
COP4610
13
Space-multiplexing Memory
5/29/2016
COP4610
14
Time-multiplexing I/O Devices
5/29/2016
COP4610
15
Multi-programmed Batch Systems
Several jobs are kept in main memory at the same time, and the
CPU is multiplexed among them.
5/29/2016
COP4610
16
OS Features for Multi-programming
• I/O routine supplied by the system
• Memory management – the system must
allocate the memory to several jobs
• CPU scheduling – the system must choose
among several jobs ready to run
• Allocation of devices
5/29/2016
COP4610
17
Time-sharing Systems
• The CPU is multiplexed among several jobs that are
kept in memory and on disk (the CPU is allocated to
a job only if the job is in memory).
• A job is swapped in and out of memory to the disk.
• On-line communication between the user and the
system is provided; when the operating system
finishes the execution of one command, it seeks the
next “control statement” not from a card reader, but
rather from the user’s keyboard.
• On-line system must be available for users to access
data and code.
5/29/2016
COP4610
18
System Call Interface
• System call interface
– Operating system provides a set of operations
called system calls
– A programming interface
5/29/2016
COP4610
19
How to Make a System Call
• For a programmer
– A system call is similar to a procedure/function
call in a traditional programming language
– System call interfaces are available in C/C++ as
library routines
– For example, fork to create a new process
• Commonly used system calls
5/29/2016
COP4610
20
How to Make a System Call – cont.
• For the system
– through a trap instruction which causes an interrupt
• Hardware saves PC and current status information
• Hardware changes mode to system mode
• Hardware loads PC from system call interrupt vector
location.
• Execute the system call interrupt handler
• return from the handler, restores PC and other saved status
information
• User process continues.
5/29/2016
COP4610
21
Trap Instruction
5/29/2016
COP4610
22
System Call Flow of Control
5/29/2016
COP4610
23
von Neumann Architecture
5/29/2016
COP4610
24
Central Processing Unit
• Datapath
– ALU – Arithmetic/Logic Unit
– Registers
• General-purpose registers
• Control registers
– Communication paths between them
• Control
– Controls the data flow and operations of ALU
5/29/2016
COP4610
25
Instruction Execution
• Instruction fetch (IF)
MAR  PC; IR  M[MAR]
• Instruction Decode (ID)
A  Rs1; B  Rs2; PC  PC + 4
• Execution (EXE)
– Depends on the instruction
• Memory Access (MEM)
– Depends on the instruction
• Write-back (WB)
5/29/2016
COP4610
26
Dual-mode Operation
• Ensure proper operation of a computer system
– Protect the operating system and all other programs and
their data from any malfunctioning program
– Protection is needed for any shared resource
• Dual-mode provides a means of doing that
– System operates in two modes
• User mode
• System mode
– Privileged instructions
• I/O instructions are privileged instructions
5/29/2016
COP4610
27
Dual-mode Operation – cont.
• System mode
– all instructions are legal
– all addresses are absolute physical addresses
(base and bound are not used)
• User mode
– instructions that modify control registers are
illegal
– all addresses must be less than bound and have
base added to them
5/29/2016
COP4610
28
Privileged Instructions
• Instructions that can only be executed in the
supervisor mode are called supervisor, privileged,
or protected instructions
• I/O instructions are privileged instructions
– A user program in user mode cannot perform its own
I/O
• Instruction to change the mode is a privileged
instruction
• Instruction to set the halt flag is a privileged
instruction
5/29/2016
COP4610
29
Device Management Organization
Application
Process
System Interface
File
Manager
Device-Independent
Device-Dependent
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
30
Device Controllers
• A hardware component to control the detailed
operations of a device
– Interface between controllers and devices
– Interface between software and the controller
• Through controller’s registers
5/29/2016
COP4610
31
Device Controllers – cont.
...
busy
Command
done
Error code
Status
...
busy done
0
0 idle
0
1 finished
1
0 working
1
1 (undefined)
Data 0
Data 1
Logic
Data n-1
5/29/2016
COP4610
32
Memory-mapped I/O – cont.
5/29/2016
COP4610
33
Device Drivers
• The part of OS that implements device
management is called collectively as device
drivers
– Device drivers can be complex
– However, the drivers for different devices
implement a similar interface so that a higherlevel component has a uniform interface for
different devices
5/29/2016
COP4610
34
I/O Strategies
• Direct I/O or DMA for data transferring
• Polling or interrupt-driven
• I/O strategies
– Direct I/O with polling
– DMA I/O with polling
• Not supported in general
– Direct I/O with interrupts
– DMA I/O with interrupts
5/29/2016
COP4610
35
Direct-Memory Access
5/29/2016
COP4610
36
Direct I/O with Polling
read(device, …);
1
System Interface
Data
read function
5
write function
2
3
4
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
37
Interrupts
• An interrupt is an immediate transfer of control caused
by an event in the system to handle real-time events
and running-time errors
–
–
–
–
Interrupt can be either software or hardware
I/O device request (Hardware)
System call (software)
Signal (software)
• Page fault (software)
• Arithmetic overflow
• Memory-protection violation
– Power failure
5/29/2016
COP4610
38
Interrupt Handling
5/29/2016
COP4610
39
Interrupt-Driven I/O
read(device, …);
1
9
8b
Data
System Interface
Device Status Table
read driver
2
4
7
Device
Handler
write driver
6
3
Interrupt
Handler
8a
5
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
40
Interrupt-Driven Versus Polling
• In general, an interrupt-driven system will
have a higher CPU utilization than a pollingbased system
– The CPU time on polling by one process may be
utilized by another process to perform
computation
5/29/2016
COP4610
41
I/O-CPU Overlap
Through interrupt-driven I/O
5/29/2016
COP4610
42
I/O-bound and Compute-bound Processes
• I/O-bound process
– A process’s overall execution time is dominated
by the time to perform I/O operations
• Compute-bound process
– A process’s time on I/O is small compared to the
amount of time spent using the CPU
• Many processes have I/O-bound and
compute-bound phases
5/29/2016
COP4610
43
Buffering
5/29/2016
COP4610
44
Optimizing Access to Rotating Devices
• Access time has two major components
– Seek time – the time for the disk arm to move the
heads to the cylinder containing the desired sector
– Rotational latency – the additional time waiting for
the disk to rotate the desired sector to the disk head
• In a multiprogramming system with many
processes, there may be several pending
requests for a disk drive
– The average accessing time can be reduced by
scheduling the pending requests
5/29/2016
COP4610
45
Randomly Accessed Devices
•Seek time dominates access time => minimize
seek time across the set
•Tracks 0:299; Head at track 76, requests for 124,
17, 269, 201, 29, 137, and 12
5/29/2016
COP4610
46
Optimizing Access to Rotating Devices
-First-Come-First-Served
5/29/2016
COP4610
47
Optimizing Access to Rotating Devices – cont.
-Shortest-Seek-First-First
5/29/2016
COP4610
48
Optimizing Access to Rotating Devices – cont.
-Scan/Look
5/29/2016
COP4610
49
Optimizing Access to Rotating Devices – cont.
- Circular Scan/
Circular Look
5/29/2016
COP4610
50
Process Manager
• Process manager consists of
– Basic algorithms and data structures to
implement the process and resource abstractions
– Managing resources used by processes/threads
– Tools to create/destroy/manipulate processes and
threads
– Scheduling
– Process synchronization
– A deadlock strategy
– Protection strategy
5/29/2016
COP4610
51
Implementing the Process Abstraction
Pi CPU
Pj CPU
Pi Executable
Memory
Pj Executable
Memory
Pk CPU
…
Pk Executable
Memory
OS Address
Space
Pi Address
Space
CPU
ALU
Pk Address
Space
…
Control
Unit
Pj Address
Space
5/29/2016
COP4610
Machine Executable Memory
OS interface
52
Modern Processes and Threads
5/29/2016
COP4610
53
Processes
• A process is a sequential program in
execution
–
–
–
–
The object program to be executed
The data on which the program will execute
Resources required by the program
The threads in the process
• A host process environment
• The status of each thread’s execution
– Thread-specific data, such as a stack, a PC, and set of
register values
5/29/2016
COP4610
54
The Address Space
Address
Space
Address
Binding
Executable
Memory
Process
Files
Other objects
5/29/2016
COP4610
55
Tracing the Hardware Process
Hardware process progress
Machine is
Powered up
Bootstrap
Process Interrupt
Loader Manager Handler P1
Load the kernel
Initialization
Execute a thread
Schedule
P,2
Pn
…
Service an interrupt
5/29/2016
COP4610
56
Context Switching
Old Thread
Descriptor
CPU
New Thread Descriptor
5/29/2016
COP4610
57
Process Descriptors
• OS creates/manages process abstraction
• Descriptor is data structure for each process
–
–
–
–
–
5/29/2016
Type & location of resources it holds
List of resources it needs
List of threads
List of child processes
Security keys
COP4610
58
Threads
• A thread shares with its peer threads its:
–
–
–
–
code section
data section
operating-system resources
collectively known as a task
• A traditional or heavyweight process is equal
to a task with one thread
5/29/2016
COP4610
59
Threads – cont.
5/29/2016
COP4610
60
Thread Abstraction
• The major tasks in managing a thread include
– Create/destroy a thread
– Allocate thread-specific resources
– Manage thread context switching
• The thread descriptor is the data structure
where the OS keeps all information to
manage that thread
5/29/2016
COP4610
61
Diagram of Process State
5/29/2016
COP4610
62
UNIX State Transition Diagram
Request
Wait by
parent
zombie
Sleeping
Done
Running
Schedule
Request
I/O Request
Start
Allocate
Runnable
I/O Complete
Traced or Stopped
Uninterruptible
Sleep
5/29/2016
Resume
COP4610
63
Process Scheduler Organization
5/29/2016
COP4610
64
Scheduling Criteria
• CPU utilization – keep the CPU as busy as possible
• Throughput – # of processes that complete their
execution per time unit
• Turnaround time – amount of time to execute a
particular process
• Response time – amount of time it takes from when
a request was submitted until the first response is
produced, not output (for time-sharing
environment)
5/29/2016
COP4610
65
First-Come-First-Served
• Gantt chart of FCFS Scheduler
5/29/2016
COP4610
66
Shortest-Job-Next Scheduling
• Associate with each process the length of its
next CPU burst.
– Use these lengths to schedule the process with
the shortest time.
• SJN is optimal
– gives minimum average waiting time /
turnaround time for a given set of processes.
5/29/2016
COP4610
67
Shortest-Job-Next Scheduling – cont.
• Two schemes:
– non-preemptive – once CPU given to the process
it cannot be preempted until completes its CPU
burst.
– Preemptive – if a new process arrives with CPU
burst length less than remaining time of current
executing process, preempt. This scheme is know
as the Shortest-Remaining-Time-Next (SRTN).
5/29/2016
COP4610
68
Shortest-Job-Next Scheduling – cont.
• Gannt chart of preemptive SJN
5/29/2016
COP4610
69
Round Robin (RR)
• Each process gets a small unit of CPU time
(time quantum), usually 10-100 milliseconds.
After this time has elapsed, the process is
preempted and added to the end of the ready
queue.
• If there are n processes in the ready queue
and the time quantum is q, then each process
gets 1/n of the CPU time in chunks of at most
q time units at once. No process waits more
than (n-1)q time units.
5/29/2016
COP4610
70
Round Robin – cont.
• Gannt chart for RR (q=4)
5/29/2016
COP4610
71
Multilevel Queue
• Ready queue is partitioned into separate
queues
– foreground (interactive)
– background (batch)
• Each queue has its own scheduling algorithm
– foreground – RR
– background – FCFS
5/29/2016
COP4610
72
Multilevel Feedback Queue
• A process can move between the various queues
• Multilevel-feedback-queue scheduler defined by the
following parameters:
–
–
–
–
–
number of queues
scheduling algorithms for each queue
method used to determine when to upgrade a process
method used to determine when to demote a process
method used to determine which queue a process will
enter when that process needs service
5/29/2016
COP4610
73
Interacting Processes
• Independent process
– Cannot affect or be affected by the other
processes in the system
– Does not share any data with other processes
• Interacting process
– Can affect or be affected by the other processes
– Shares data with other processes
– We focus on interacting processes through
physically or logically shared memory
5/29/2016
COP4610
74
Race Condition
• Race condition
– When several processes access and manipulate
the same data concurrently, there is a race among
the processes
– The outcome of the execution depends on the
particular order in which the access takes place
– This is called a race condition
5/29/2016
COP4610
75
Bounded-Buffer
5/29/2016
COP4610
76
Bounded-Buffer - cont.
• Suppose we have one producer and one
consumer, the variable counter is 5
– Producer: counter = counter +1
P1: load counter, r1
P2: add r1, #1, r2
P3: store r2, counter
– Consumer: counter = counter - 1
C1: load counter, r1
C2: add r1, #-1, r2
C3: store r2, counter
5/29/2016
COP4610
77
Bounded-Buffer - cont.
• A particular execution sequence
– P1: load counter, r1
– P2: add r1, #1, r2
--- Context switch ---– C1: load counter, r1
– C2: add r1, #-1, r2
– C3: store r2, counter
--- Context switch ---– P3: store r2, counter
– What is the value of counter?
5/29/2016
COP4610
78
The Critical-Section Problem
• n processes all competing to use some shared
data
• Each process has a code segment, called
critical section, in which the shared data is
accessed.
• Problem – ensure that when one process is
executing in its critical section, no other
process is allowed to execute in its critical
section, called mutual exclusion
5/29/2016
COP4610
79
The Critical-Section Problem – cont.
• Structure of process Pi
repeat
entry section
critical section
exit section
reminder section
until false;
5/29/2016
COP4610
80
Requirements for Critical-Section Solutions
• Mutual Exclusion.
– If process Pi is executing in its critical section, then no
other processes can be executing in their critical sections.
• Progress
– If no process is executing in its critical section and there
exist some processes that wish to enter their critical
section, then the selection of the processes that will enter
the critical section next cannot be postponed indefinitely.
• Bounded Waiting
– A bound must exist on the number of times that other
processes are allowed to enter their critical sections after
a process has made a request to enter its critical section
and before that request is granted.
5/29/2016
COP4610
81
Algorithm 1
• Shared variables:
– var turn: (0..1);
initially turn = 0
– turn - i  Pi can enter its critical section
• Process Pi
repeat
while turn  i do no-op;
critical section
turn := j;
reminder section
until false;
• Satisfies mutual exclusion, but not progress
5/29/2016
COP4610
82
Algorithm 2
• Shared variables
– var flag: array [0..1] of boolean;
initially flag [0] = flag [1] = false.
– flag [i] = true  Pi ready to enter its critical section
• Process Pi
repeat
flag[i] := true;
while flag[j] do no-op;
critical section
flag [i] := false;
remainder section
until false;
• Satisfies mutual exclusion, but not progress requirement.
5/29/2016
COP4610
83
Proposed Algorithm 3
• Shared variables:
– boolean lock;
initially lock = FALSE
– lock is FALSE  Pi can enter its critical section
• Process P1
do
Process P2
do
while (lock) do no-op;
lock = TRUE;
critical section
lock = FALSE;
reminder section
while(TRUE);
while (lock) do no-op;
lock = TRUE;
critical section
lock = FALSE
reminder section
while(TRUE);
5/29/2016
COP4610
84
Solution through Disabling Interrupts – cont.
• Process Pi
repeat
disableInterrupts(); //entry section
critical section
enableInterrupts(); //exit section
reminder section
until false;
5/29/2016
COP4610
85
Solution through Disabling Interrupts – cont.
• This solution may affect the behavior of the I/O
system
– Interrupts can be disabled for an arbitrarily long time
• The interrupts can be disabled permanently if the program
contains an infinite loop in its critical section
– User programs are not allowed to enable and disable
interrupts directly
• However, if the operating system can provide system calls,
a user can use the system calls for synchronization
– Called semaphores and related system calls
5/29/2016
COP4610
86
Synchronization Hardware
• Test and modify the content of a word atomically
(indivisibly)
– The procedure cannot be interrupted until it has completed the
routine
– Implemented as a test-and-set instruction
boolean Test-and-Set (boolean target)
{ boolean tmp
tmp = target;
target = true;
return tmp;
}
5/29/2016
COP4610
87
Semaphores
• Semaphore S – non-negative integer variable
– Binary semaphore – can only be either 0 or 1
– Counting semaphore – can be any positive number
• It can only be changed or tested via two
indivisible (atomic) operations
– P(S) or wait(S)
P(S): while S 0 do no-op;
S := S – 1;
– V(S) or signal(S)
P(S): S := S + 1;
5/29/2016
COP4610
88
Example:Mutual Exclusion using Semaphores
• Shared variables
– semaphore mutex;
• Process Pi
repeat
P(mutex);
critical section
P(mutex);
remainder section
until false;
How shall we initialize the semaphore mutex in order
to achieve mutual exclusion?
5/29/2016
COP4610
89
Bounded-Buffer using Semaphores – cont.
5/29/2016
COP4610
90
The Readers-Writers Problem
• A resource is shared among readers and
writers
– A reader process can share the resource with any
other reader process but not with any writer
process
– A writer process requires exclusive access to the
resource whenever it acquires any access to the
resource
5/29/2016
COP4610
91
First and Second Policy
5/29/2016
COP4610
92
Readers-writers with active readers – cont.
5/29/2016
COP4610
93
Writer Precedence
reader() {
writer() {
while(TRUE) {
while(TRUE) {
<other computing>;
<other computing>;
P(writePending);
P(mutex2);
P(readBlock);
writeCount++;
P(mutex1);
if(writeCount == 1)
readCount++;
P(readBlock);
if(readCount == 1)
V(mutex2);
P(writeBlock);
P(writeBlock);
V(mutex1);
access(resource);
V(readBlock);
V(writeBlock);
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);
Issues Using Semaphores
• Deadlock
– two or more processes are waiting indefinitely 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
P(S);
P(Q);

V(S);
V(Q)
5/29/2016
P1
P(Q);
P(S);

V(Q);
V(S);
COP4610
95
Monitors
• High-level synchronization construct that
allows the safe sharing of an abstract data
type among concurrent processes.
class monitor {
variable declarations
semaphore mutex = 1;
public P1 :(…)
{ P(mutex);
........
V(mutex);
};
........
}
5/29/2016
COP4610
96
Monitors – cont.
• To allow a process to wait within the monitor, a condition
variable must be declared, as
condition x, y;
• Condition variable can only be used with the operations wait
and signal.
– The operation
x.wait;
means that the process invoking this operation is suspended until
another process invokes
x.signal;
– The x.signal operation resumes exactly one suspended process. If no
process is suspended, then the signal operation has no effect.
5/29/2016
COP4610
97
Monitors – cont.
5/29/2016
COP4610
98
Inter-Process Communication
• Inter-Process Communication (IPC)
– Allow running processes to communicate with
each other
• IPC – special cases
– Parent and child
• Parent passes arguments to child
• Parent collect returned status from child using wait
– Processes with common ancestors
• pipe
5/29/2016
COP4610
99
Communication through Messages – cont.
• IPC facility provides two operations:
– send(message) – message size fixed or variable
– receive(message)
• If P and Q wish to communicate, they need to
– establish a communication link between them
– exchange messages via send/receive
5/29/2016
COP4610
100
Simultaneous Semaphores
• The orders of P operations on semaphores are
critical
– Otherwise deadlocks are possible
• Simultaneous semaphores
– Psimultaneous(S1, ...., Sn)
– The process gets all the semaphores or none of
them
5/29/2016
COP4610
101
UNIX Signal
• A signal in UNIX is a mechanism by which
the OS can inform a process of the
occurrence of some event
– A signal can be raised by one process using kill
system call, thus causing another process to be
interrupted and to optionally catch the signal
– Signals can also be used among user processes
5/29/2016
COP4610
102
Download