Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
CSI 3131Greatest Hits (2015)
Modules 1-4
Content from: Silberchatz
Winter 2015 2
I/O Structure• Controller has registers for accepting commands and
transferring data (i.e. data-in, data-out, command, status)
• Device driver for each device controller talks to the controller
– The driver is the one who knows details of controller
– Provides uniform interface to kernel
• I/O operation
– Device driver loads controller registers appropriately
– Controller examines registers, executes I/O
Winter 2015 3
I/O Structure• How does the driver know when the I/O
completes?– Periodically read the status register
• Called direct I/O
• Low overhead if I/O is fast
• If I/O is slow, lots of busy waiting
• Any idea how to deal with slow I/O?– Do something else and let the controller
signal device driver (raising and interrupt) that I/O has completed
• Called interrupt-driver I/O
• More overhead, but gets rid of busy waiting
Winter 2015 4
I/O Structure
• Interrupt – driven I/O still has lots of overhead if used for bulk data transfer– An interrupt for each byte is too much
• Ideas?– Have a smart controller that can talk directly
with the memory
– Tell the controller to transfer block of data to/from memory
– The controller raises interrupt when the transfer has completed
– Called Direct Memory Access (DMA)
Winter 2015 5
What Do Operating Systems?– OS is program most involved with the
hardware
• hardware abstraction
– OS is a resource allocator
• Manages all resources
• Decides between conflicting requests for
efficient and fair resource use
– OS is a control program
• Controls execution of programs to prevent errors
and improper use of the computer
Winter 2015 6
Defining Operating Systems• No universally accepted definition
• “Everything a vendor ships when you order an
operating system” is good approximation
– But varies wildly (see system programs)
• “The one program running at all times on the
computer” is the one generally used in this course
– This is the kernel
– Everything else is either a system program (ships with
the operating system) or an application program
Winter 2015 7
Operating System ServicesServices provided to user programs:
– I/O operations
• User program cannot directly access I/O hardware, OS does
the low level part for them
– Communications
• Both inter-process on the same computer, and between
computers over a network
• via shared memory or through message passing
– Error detection
• Errors do occur: in the CPU and memory hardware, in I/O
devices, in user programs
• OS should handle them appropriately to ensure correct and
consistent computing
• Low level debugging tools really help
Winter 2015 8
Operating System Services (Cont.)Services for ensuring efficient operation of the system
itself– Resource allocation and management
• Needed when there are multiple users/ multiple jobs running concurrently
• Some resources need specific management code
– CPU cycles, main memory, file storage
• Others can be managed using general code - I/O devices
– Accounting
• Which users use how much and what kinds of computer resources
– Protection and security
• Between different processes/user in the computer
• From the outsiders in a networked computer system
• Protection: ensuring that all access to system resources is controlled
• Security: user authentication, defending external I/O devices from invalid access attempts
Winter 2015 9
Operating-System Operations• OS is interrupt driven
• Interrupts raised by hardware and software – Mouse click, division by zero, request for operating
system service
– Timer interrupt (i.e. process in an infinite loop), memory access violation (processes trying to modify each other or the operating system)
• Some operations should be performed only by a trusted party– Accessing hardware, memory-management registers
– A rogue user program could damage other programs, steal the system for itself, …
– Solution: dual-mode operation
Winter 2015 10
Transition from User to Kernel Mode• Dual-mode operation allows OS to protect itself and other system
components
– User mode and kernel mode
– Mode bit provided by hardware
• Provides ability to distinguish when system is running user code or kernel code
• Some instructions designated as privileged, only executable in kernel mode
• System call changes mode to kernel, return from call resets it to user
Winter 2015 11
System Calls• Programming interface to the services provided by
the OS
– Process control
• i.e. launch a program
– File management
• i.e. create/open/read a file, list a directory
– Device management
• i.e. request/release a device
– Information maintenance
• i.e. get/set time, process attributes
– Communications
• i.e. open/close connection, send/receive messages
Winter 2015 12
Main Operations of an Operating System• Process Management
– Program is passive, process is active, unit of work within system
– OS manages resources required by processes
• CPU, memory, I/O, files
• Initialization data
– OS manages process activities: e.g. creation/deletion, interaction between processes, etc.
• Memory Management
– Memory management determines what and when is in memory to
optimize CPU utilization and computer response to users
• Storage Management
– OS provides uniform, logical view of information storage
– File Systems, Mass Storage Management
• I/O SubSystem
– One purpose of OS is to hide peculiarities of hardware devices from the user
Operating System Structure
• Monolithic
• Layered
• Microkernel
• Modular
• Hybrid
• Which leads to Virtual Machines
14
Process state transitions
New Ready
Represents the creation of the process.
• In the case of batch systems – a list of waiting in new
state processes (i.e. jobs) is common.
Ready Running
When the CPU scheduler selects a process for
execution.
Running Ready
Happens when an interruption caused by an event
independent of the process
• Must deal with the interruption – which may take away the
CPU from the process
• Important case: the process has used up its time with the
CPU.
15
Process state transitions
Running Waiting
When a process requests a service from the OS and
the OS cannot satisfy immediately (software interruption
due to a system call)
• An access to a resource not yet available
• Starts an I/O: must wait for the result
• Needs a response from another process
Waiting Ready
When the expected event has occurred.
Running Terminated
The process has reached the end of the program (or an
error occurred).
16
Process Control Block (PCB)
17
Schedulers• Long-term scheduler (or job scheduler)
– selects which new processes should be brought into the
memory; new ready (and into the ready queue from a job spool queue) (used in batch systems)
• Short-term scheduler (or CPU scheduler)
– selects which ready process should be executed next; ready running
• Which of these schedulers must execute really fast, and which one can be slow? Why?
• Short-term scheduler is invoked very frequently (milliseconds) (must be fast)
• Long-term scheduler is invoked very infrequently (seconds, minutes) (may be slow)
18
Schedulers (Cont.)• Processes differ in their resource utilization:
– I/O-bound process – spends more time doing I/O than computations, many short CPU bursts
– CPU-bound process – spends more time doing computations; few very long CPU bursts
• The long-term scheduler controls the degree of multiprogramming– the goal is to efficiently use the computer
resources
– ideally, chooses a mix of I/O bound and CPU-bound processes
• but difficult to know beforehand
19
Medium Term Scheduling Due to memory shortage, the OS might decide to
swap-out a process to disk.
Later, it might decide to swap it back into memory
when resources become available
Medium-term scheduler – selects which process
should be swapped out/in
20
Process CreationSo, where do all processes come from?
– Parent process create children processes, which, in turn create other processes, forming a tree of processes
– Usually, several properties can be specified at child creation time:
• How do the parent and child share resources?– Share all resources– Share subset of parent’s resources– No sharing
• Does the parent run concurrently with the child?– Yes, execute concurrently– No, parent waits until the child terminates
• Address space– Child duplicate of parent– Child has a program loaded into it
21
Process Creation (Cont.)UNIX example:
– fork() system call creates new process with the duplicate address space of the parent
• no shared memory, but a copy
• copy-on-write used to avoid excessive cost
• returns child’s pid to the parent, 0 to the new child process
• the parent may call wait() to wait until the child terminates
– exec(…) system call used after a fork() to replace the process’ memory space with a new program
22
Fork exampleint pid, a = 2, b=4;
pid = fork(); /* fork another process */
if (pid < 0) exit(-1); /* fork failed */
else if (pid == 0) { /* child process */
a = 3; printf(“%d\n”, a+b);
} else {
wait();
b = 1;
printf(“%d\n”, a+b);
}
What would be the output printed?
7
3
23
Process TerminationHow do processes terminate?
• Process executes last statement and asks the operating system to delete it (by making exit() system call)
• Abnormal termination
– Division by zero, memory access violation, …
• Another process asks the OS to terminate it
– Usually only a parent might terminate its children
• To prevent user’s terminating each other’s processes
– Windows: TerminateProcess(…)
– UNIX: kill(processID, signal)
24
Process TerminationWhat should the OS do?
• Release resources held by the process
– When a process has terminated, but not all of its resources has been released, it is in state terminated (zombie)
• Process’ exit state might be sent to its parent
– The parent indicates interest by executing wait() system call
What to do when a process having children is exiting?
• Some OSs (VMS) do not allow children to continue
– All children terminated - cascading termination
• Other find a parent process for the orphan processes
25
Interprocess Communication (IPC)• Mechanisms for processes to communicate and
to synchronize their actions
– Fundamental models of IPC
• Through shared memory (shmget & shmat)
• Using message passing
– Examples of IPC mechanisms
• signals
• pipes & sockets
• Semaphores
• Monitor
• RPC
26
Direct Communication• Processes must name each other explicitly:
– send (P, message) – send a message to process P
– receive(Q, message) – receive a message from process Q
• Properties of the communication link
– Links are established automatically, exactly one link for each pair of communicating processes
– The link may be unidirectional, but is usually bi-directional
27
Blocking Message Passing
Also called synchronous Blocking message passing
• sender waits until the receiver receives the message
• receiver waits until the sender sends the message
• advantages:
– inherently synchronizes the sender with the receiver
– single copying sufficient (no buffering)
• disadvantages:
– possible deadlock problem
28
Non-Blocking Message Passing
Also called asynchronous message passing
• Non-blocking send: the sender continues before the delivery of the message
• Non-blocking receive: check whether there is a message available, return immediately
29
Unix Pipesint fd[2], pid, ret;
ret = pipe(fd);
if (ret == -1) return PIPE_FAILED;
pid = fork();
if (pid == -1) return FORK_FAILED;
if (pid == 0) { /* child */
close(fd[1]);
while(…) {
read(pipes[0], …);
…
}
} else { /* parent */
close(fd[0]);
while(…) {
write(fd[1], …);
…
}
}
30
After Spawning New Child Process
Kernel
0 1 2 3 4
Parent Process
. . .
pipe
0 1 2 3 4
Child Process
. . .
31
After Closing Unused Ends of Pipe
Kernel
0 1 2 3 4
Parent Process
. . .
pipe
0 1 2 3 4
Child Process
. . .
32
Process Characteristics
• These 2 characteristics are most often treated independently by OS’s
• Execution is normally designated as execution thread
• Resource ownership is normally designated as process or task
33
Threads vs ProcessesProcess
• A unit/thread of execution, together with code, data and other resources to support the execution.
Idea
• Make distinction between the resources and the execution threads
• Could the same resources support several threads of execution?– Code, data, .., - yes
– CPU registers, stack - no
34
Threads = Lightweight Processes
• A thread is a subdivision of a process– A thread of control in the process
• Different threads of a process share the address space and resources of a process.– When a thread modifies a global variable (non-
local), all other threads sees the modification
– An open file by a thread is accessible to other threads (of the same process).
35
Motivation for Threads• Responsiveness
– One thread handles user interaction
– Another thread does the background work (i.e. load web page)
• Utilization of multiprocessor architectures
– One process/thread can utilize only one CPU
– Many threads can execute in parallel on multiple CPUs
• Well, but all this applies to one thread per process as well –why use threads?
36
Many to One Model
Properties:– Cheap/fast, but runs as one process to the OS
scheduler
– What happens if one thread blocks on an I/O?• All other threads block as well
– How to make use of multiple CPUs?• Not possible
Examples:– Solaris Green Threads
– GNU Portable Threads
37
One to One Model
Properties:
– Usually, limited number of threads
– Thread management is relatively costly
– But, provides better concurrency of threads
Examples:
– Windows NT/XP/2000
– Linux
– Solaris Version 9 and later
38
Many-to-Many Model• Allows many user level threads to be
mapped to many kernel threads
• The thread library cooperates with the OS to dynamically map user threads to kernel threads
• Intermediate costs and most of the benefits of multithreading
– If a user thread blocs, its kernel thread can be associated to another user thread
– If more than one CPU is available, multiple kernel threads can be run concurrently
Examples:
Solaris prior to version 9
Windows NT/2000 with the
ThreadFiber package
39
Threading Issues - Scheduler Activations
• The many to many models (including two level) require communication from the kernel to inform the thread library when a user thread is about to block, and when it again becomes ready for execution
• When such event occurs, the kernel makes an upcallto the thread library
• The thread library’s upcall handler handles the event (i.e. save the user thread’s state and mark it as blocked)
40
Threading Issues – Creation/TerminationThread Cancellation
• Terminating a thread before it has finished
• Two general approaches:– Asynchronous cancellation terminates the target
thread immediately• Might leave the shared data in corrupt state
• Some resources may not be freed
– Deferred cancellation• Set a flag which the target thread periodically checks to
see if it should be cancelled
• Allows graceful termination
41
Threading Issues - Signal Handling• Signals are used in UNIX systems to notify a process that a
particular event has occurred
• Essentially software interrupt
• A signal handler is used to process signals
1. Signal is generated by particular event
2. Signal is delivered to a process
3. Signal is handled
• Options:
– Deliver the signal to the thread to which the signal applies
– Deliver the signal to every thread in the process
– Deliver the signal to certain threads in the process
– Assign a specific thread to receive all signals for the process
42
Linux Threads• Linux refers to them as tasks rather than threads
• Thread creation is done through clone() system call
• The clone() system call allows to specify which resources are shared between the child and the parent
– Full sharing threads
– Little sharing like fork()
43
Thread Programming ExerciseGoal: Write multithreaded matrix multiplication algorithm, in order to
make use of several CPUs.
Single threaded algorithm for multiplying n x n matrices A and B :
For (i=0; i<n; i++)For (j=0; j<n; j++) {
C[i,j] = 0;For (k=0; k<n; k++)
C[i,j] += A[i,k] * B[k,j];}
Just to make our life easier:
Assume you have 6 CPUs and n is multiple of 6.
44
Multithreaded Matrix MultiplicationIdea:
• create 6 threads
• have each thread compute 1/6 of the matrix C
• wait until everybody finished
• the matrix can be used now
Thread 0
Thread 1
Thread 2
Thread 3
Thread 4
Thread 5
45
PThreadspthread_t tid[6];
pthread_attr_t attr;
int id[6];
int i;
pthread_init_attr(&attr);
for(i=0; i<6; i++) /* create the working threads */
{
id[i] = i;
pthread_create( &tid[i], &attr, worker, &id);
}
for(i=0; i<6; i++) /* now wait until everybody finishes */
pthread_join(tid[i], NULL);
/* the matrix C can be used now */
…
46
PThreadsvoid *worker(void *param)
{
int i,j,k;
int id = *((int *) param); /* take param to be
pointer to integer */
int low = id*n/6;
int high = (id+1)*n/6;
for(i=low; i<high; i++)
for(j=0; j<n; j++)
{
C[i,j] = 0;
for(k=0; k<n; k++)
C[i,j] = A[i,k]*B[k,j];
}
pthread_exit(0);
}
47
Synchronization problem• Concurrent processes (or threads) often need to
share data (maintained either in shared memory or
files) and resources
• If there is no controlled access to shared data, some
processes will obtain an inconsistent view of this
data
• The results of actions performed by concurrent
processes will then depend on the order in which
their execution is interleaved – race condition
• Let us abstract the danger of concurrent modification
of shared variables into the critical-section problem.
48
Critical-Section Problem• The piece of code modifying the shared variables where a
thread/process needs exclusive access to guarantee consistency is called critical section.
• The general structure of each thread/process can be seen as follows:
while (true)
{
entry_section
critical section (CS)
exit_section
remainder section (RS)
}
• Critical (CS) and remainder (RS) sections are given,
• We want to design entry and exit sections so that the following requirements are satisfied:
49
Solution Requirements for CSP1. Mutual Exclusion - If process Pi is executing in its critical
section, then no other processes can be executing in their critical sections
2. Progress - If there exist some processes wishing to enter their CS and no process is in their CS, then one of them will eventually enter its critical section.
No deadlock
Non interference – if a process terminates in the RS, other processes should still be able to access the CS.
Assume that a thread/process always exits its CS.
3. 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
No famine.
Assumptions Assume that each process executes at a nonzero speed No assumption concerning relative speed of the N processes Many CPUs may be present but memory hardware prevents
simultaneous access to the same memory location No assumption about the order of interleaved execution
51
Task T0:
flag[0] = true;
// T0 wants in
turn = 1;
// T0 gives a chance to T1
while
(flag[1]==true&&turn==1){}
// Wait if T1 wants in and it
is his turn!!!
Critical Section
flag[0] = false;
// T0 wants out
Remainder Section
Task T1:
flag[1] = true;
// T1 wants in
turn = 0;
// T1 gives a chance to T0
while
(flag[0]==true&&turn==0){}
// Wait if T0 wants in and it
is his turn!!!
Critical section
flag[1] = false;
// T1 wants out
Remainder Section
Peterson’s Solution (see book) Assume only two process 0 and 1
Use the flag i to indicate willingness to enter CS
But use turn to let the other task enter the CS
52
Hardware Solution: disable
interruptsSimple solution:
– A process would not be preempted in its CS
Process Pi:
while(true)
{
disable interrupts
critical section
enable interrupts
remainder section
}Discussion:
Efficiency deteriorates: when a process is in its CS, it’s impossible to
interlace the execution of other processes in their RS.
Loss of interruptions
On a multiprocessor system: mutual exclusion is not assured.
A solution that is not generally acceptable.
Solutions
Peterson’s
Solution
(Software)
Hardware
Solutions
Semaphores
Monitors
53
The test-and-set instruction (cont.)• Mutual exclusion is assured: if Ti enters the
CS, the other Tj are busy waiting.
– Problem: still using busy waiting.
• Can easily attain mutual exclusion, but
needs more complex algorithms to satisfy
the other requirements to the CSP.
– When Ti leaves its CS, the selection of the
next Tj is arbitrary: no bounded waiting:
starvation is possible.
54
Spinlocks: Busy Wait Semaphores
• Easiest way to implement semaphores.
• Used in situations where waiting is brief or with multi-processors.
• When S=n (n>0), up to n processes will not block when calling wait().
• When S becomes 0, processes block in the call wait() up until signal() is called.
• A call to signal() unblocks a blocked process or increments the semaphore value.
wait(S)
{
while(S<=0);//no-op
S--;
}
signal(S)
{
S++;
}
The sequence S<=0, S–- must
be atomic.
The signal call must be atomic.
55
Semaphores – Version 2 – no busy wait
• When a process must wait for a semaphore to become
greater than 0, place it in a queue of processes waiting
on the same semaphore
• The queues can be FIFO, with priorities, etc. The OS
controls the order in which processes are selected from
the queue.
• Thus wait and signal become system calls similar to
requests for I/O.
• There exists a queue for each semaphore similar to the
queues defined for each I/O device.
56
Atomic execution of the wait() and signal() calls• wait() and signal() are in fact critical sections.• Can we use semaphores for these critical sections?• one processor: inhibit (scheduler) interrupts during CS• With single processor systems
– Can disable interrupts– Operations are short (about 10 instructions)
• With SMP systems (inhibit interrupts on each processor?)– Spinlocks– Other software and hardware CSP solutions.
• Result: we have not eliminated busy waiting– But the busy waiting has been reduced considerably (to the wait()
and signal() calls); moved from entry section to CS– The semaphores (version 2), without busy wait, are used within
applications that can spend long periods in their critical section (or blocked on a semaphore waiting for a signal) – many minutes or even hours.
• Our synchronization solution is thus efficient.
57
The Bounded Buffer problem
• A producer process produces information that is consumed by a consumer process
– Ex1: a print program produces characters that are consumed by a printer
– Ex2: an assembler produces object modules that are consumed by a loader
• We need a buffer to hold items that are produced and eventually consumed
• A common paradigm for cooperating processes
58
There are two types of processes accessing a shared database
– readers only read the data, but do not modify them
– writers that want to modify the data
In order to maintain consistency, as well as efficiency, the following rules are used
– Several readers can access the database simultaneously
– A writer needs to have an exclusive access to the database (has a critical section)
• No readers or other writers are allowed while a writer is writing
– What to do if there are several readers in the system and a writer arrives? Two options:
• While there is a reader active, do not have new readers wait (first readers-writers problem).
• No new reader is admitted if there is a writer waiting (second readers-writers problem).
• Both might lead to starvation
Readers-Writers Problem
59
The Dining Philosophers Problem
• 5 philosophers think, eat, think,
eat, think ….
• In the center a bowl of rice.
• Only 5 chopsticks available.
• Require 2 chopsticks for eating.
• A classical synchronization.
problem
• Illustrates the difficulty of
allocating resources among
process without deadlock and
starvation
60
Advantages of semaphores (relative to other synchr. solutions)
Single variable (data structure) per critical
section.
Two operations: wait, signal
Can be applied to more than 2 processes.
Can have more than a single process enter
the CS.
Can be used for general synchronization.
Service offered by OS, including blocking and
queue management.
61
Problems with semaphores: programming difficulty
Wait and signal are scattered across different
programs and running threads/processes
Not always easy to understand the logic
Usage must be correct in all
threads/processes
One « bad » thread/process can make a
collection of threads/processes fail (e.g. forget a
signal)
62
• Is a software module (ADT – abstract data type)
containing:
– one or more procedures
– an initialization sequence
– local data variables
• Characteristics:
– local variables accessible only by monitor’s procedures
– a process enters the monitor by invoking one of it’s
procedures
– only one process can be executing in the monitor at any
one time (but a number of threads/processes can be waiting in the
monitor).
Monitors
63
• The monitor ensures mutual exclusion: no need to program this constraint explicitly
• Hence, shared data are protected by placing them in the monitor
– The monitor locks the shared data on process entry
• Process synchronization is done by the programmer by using condition variablesthat represent conditions a process may need to wait for before executing in the monitor
Monitors