operating systems mehdi naghavi [email protected] winter 1385

109
Operating Systems Mehdi Naghavi [email protected] Winter 1385

Upload: ethel-cain

Post on 26-Dec-2015

220 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Operating Systems

Mehdi [email protected]

Winter 1385

Page 2: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

2

Class outline

Introduction and Overview Processes Operating system structures Memory management Scheduling Input/Output File Systems Security

Page 3: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Operating Systems

Mehdi [email protected]

Winter 1385

Processes

Page 4: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

4

Overview:

ProcessesThreadsScheduling Interprocess communicationClassical IPC problems

Page 5: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Processes

Mehdi [email protected]

Winter 1385

Page 6: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

6

What is a process?

Code, data, and stack Usually (but not always) has its own address space (address space: code, data, resource index: open files, child process, handler,.. )

Program state Program counter (current location in the code) CPU registers Stack pointer

Only one process can be running in the CPU at any given time! All executable programs are organized to multi ordinal process Each process have a virtual CPU (CPU switch)

Page 7: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

7

The process model

Multiprogramming of four programs

Conceptual model 4 independent

processes Processes run

sequentially Only one program

active at any instant! That instant can be

very short…

A

C

D

Single PC(CPU’s point of view)

AB

C D

Multiple PCs(process point of view)

B

B

ABCD

Time

Page 8: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

8

When is a process created?

Processes can be created in two ways System initialization: one or more processes created when

the OS starts up Execution of a process creation system call

System calls can come from User request to create a new process (system call executed

from user shell) Execute a batch job Already running processes

User programs System daemons (A program that runs in the background whenever needed, carring out

tasks for the users. They sleep’ until something comes along which needs their help; most commonly found on unix systems )

Page 9: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

9

When do processes end?

Conditions that terminate processes can be Voluntary

Normal exitError exit

InvoluntaryFatal errorKilled by another process

Page 10: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

10

Process hierarchies

Parent creates a child process Child processes can create their own children

Forms a hierarchy UNIX calls this a “process group”

If a process exits, its children are “inherited” by the exiting process’s parent

Windows has no concept of process hierarchy All processes are created equal

Page 11: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

11

Blocked(waiting)

Created

Exit

Ready

Running

Process states

Process in one of 5 states Created Ready Running Blocked Exit

Transitions between states1 - Process enters ready queue2 - Scheduler picks this process3 - Scheduler picks a different

process4 - Process waits for event (such as

I/O)5 - Event occurs6 - Process exits7 - Process ended by another

process

1

5

4

32

7

76

admitted

exit

interrupt

scheduler dispatch

I/O or event wait

I/O or event completion

Page 12: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

12

Implementation of Processes

Two “layers” for processes Lowest layer of process-structured OS handles interrupts,

scheduling Above that layer are sequential processes

Processes tracked in the process table or Process Control Block (PCB) Each process has a process table entry

Scheduler

0 1 N-2 N-1…

Processes

Page 13: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

13

Process Control Block (PCB)

Page 14: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

14

What’s in a process table entry?

File managementRoot directoryWorking (current) directoryFile descriptorsUser IDGroup ID

Memory managementPointers to text, data, stack

orPointer to page table

Process managementRegistersProgram counterCPU status wordStack pointerProcess statePriority / scheduling parametersProcess IDParent process IDSignalsProcess start timeTotal CPU usage

May bestored

on stack

Page 15: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

15

CPU Switch From Process to Process

Page 16: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

16

What happens on a trap/interrupt?

1. Hardware saves PC (on stack or in a special register)2. Hardware loads new PC, identifies interrupt3. Assembly language routine saves registers4. Assembly language routine sets up stack5. Assembly language calls C to run service routine6. Service routine calls scheduler7. Scheduler selects a process to run next (might be the

one interrupted…)8. Assembly language routine loads PC & registers for

the selected process

Page 17: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

17

Process Scheduling Queues

Job queue – set of all processes in the system

Ready queue – set of all processes residing in main memory, ready and waiting to execute

Device queues – set of processes waiting for an I/O device

Processes migrate among the various queues

Page 18: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

18

Ready Queue And I/O Device Queues

Page 19: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

19

Representation of Process Scheduling

Page 20: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Threads

Mehdi [email protected]

Winter 1385

Page 21: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

21

Threads: “processes” sharing memory

Process == address space Thread == program counter / stream of instructions Thread == Lightweight process Two examples

Three processes, each with one thread One process with three threads

Kernel Kernel

ThreadsThreadsSystem

space

Userspace

Process 1 Process 2 Process 3 Process 1

Page 22: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

22

Single and Multithreaded threads Processes

Page 23: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

23

Process & thread information

Per process itemsAddress spaceOpen filesChild processesSignals & handlersAccounting infoGlobal variables

Per thread itemsProgram counterRegistersStack & stack pointerState

Per thread itemsProgram counterRegistersStack & stack pointerState

Per thread itemsProgram counterRegistersStack & stack pointerState

Page 24: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

24

Threads & Stacks

Kernel

Process

Thread 1 Thread 2 Thread 3

Thread 1’sstack

Thread 3’sstack

Thread 2’sstack

User space

=> Each thread has its own stack!

Page 25: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

25

Why use threads?

Simpler programming model Less waiting Threads are faster to create or

destroy No separate address space

Overlap computation and I/O Could be done without threads,

but it’s harder Example: word processor

Thread to read from keyboard Thread to format document Thread to write to disk

Kernel

When in the Course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.--That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, --That whenever any Form of Government becomes

destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness. Prudence, indeed, will dictate that Governments long established should not be changed for light and transient causes; and accordingly all

Page 26: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

26

Multithreaded Web server

Kernel

Networkconnection

Dispatcherthread

Workerthread

Web pagecache

while(TRUE) { getNextRequest(&buf); handoffWork(&buf);

}

while(TRUE) { waitForWork(&buf); lookForPageInCache(&buf,&page); if(pageNotInCache(&page)) { readPageFromDisk(&buf,&page); } returnPage(&page);

}

Page 27: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

How threads differ from processes

27

• processes are typically independent, while threads exist as subsets of a process

• processes carry considerably more state information than threads, whereas multiple threads within a process share process state as well as memory and other resources

• processes have separate address spaces, whereas threads share their address space

• processes interact only through system-provided inter-process communication mechanisms

• Context switching between threads in the same process is typically faster than context switching between processes.

Page 28: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

28

Three ways to build a server

Thread model Parallelism Blocking system calls

Single-threaded process: slow, but easier to do No parallelism Blocking system calls

Finite-state machine Each activity has its own state States change when system calls complete or interrupts

occur Parallelism Nonblocking system calls Interrupts

Page 29: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

29

Implementing threads

Kernel

Run-timesystem

Threadtable

Processtable

Kernel

Thread

Process

Threadtable

Processtable

User-level threads+ No need for kernel support- May be slower than kernel threads- Harder to do non-blocking I/O

Kernel-level threads+ More flexible scheduling+ Non-blocking I/O- Not portable

Page 30: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

30

User Threads

Thread management done by user-level threads library

Three primary thread libraries: POSIX Pthreads Win32 threads Java threads

User threads are supported above the kernel and are managed without kernel support

Page 31: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

31

Kernel Threads

Kernel threads supported and managed directly by the OS

Examples Windows XP/2000 Solaris Linux Tru64 UNIX Mac OS X

Page 32: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

32

Multithreading Models

Many-to-One Many user threads mapped to a single kernel thread

One-to-One Each user thread mapped to a unique kernel thread

Many-to-Many Many user threads multiplexed among a potentially

smaller set of underlying kernel threads

Page 33: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

33

Many-to-One Model

Page 34: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

34

Many-to-One

Many user-level threads mapped to single kernel thread Examples:

Solaris Green Threads GNU Portable Threads

Efficient Thread management done by the thread library Don’t need to block for system calls during management

Drawback Entire process will block if any thread makes a blocking

system call (say, for I/O). Can’t leverage multi-processing architectures, because only

one user-level thread can access the kernel at a time

Page 35: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

35

One-to-one Model

Page 36: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

36

One-to-One

Each user-level thread maps to kernel thread Examples

Windows NT/XP/2000 Linux Solaris 9 and later

Efficient: Provides more concurrency than the Many-to-One model Allows multiple threads to run in parallel on multi-processors

Drawback: Creating user thread requires creating a unique kernel thread Overhead of kernel-thread creation can burden performance

Page 37: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

37

Many-to-Many Model

Page 38: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

38

Many-to-Many Model

Allows many user level threads to be mapped to many kernel threads

Allows the operating system to create a sufficient number of kernel threads

Examples: Solaris prior to version 9 Windows NT/2000 with the ThreadFiber package

Advantages over Many-to-One and One-to-One models: Developers can create as many user threads as necessary Corresponding kernel threads can execute in parallel Other threads can execute while another thread blocks

Page 39: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

39

Two-level Model

Page 40: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

40

Two-level Model

Similar to Many toMany, except that it allows a user thread to be bound to kernel thread

Examples IRIX HP-UX Tru64 UNIX Solaris 8 and earlier

Page 41: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

41

Solaris Multithreaded Architecture Example

Page 42: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Scheduling

Mehdi [email protected]

Spring 1386

Page 43: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

43

Scheduling

What is scheduling? Goals Mechanisms

Scheduling on batch systems Scheduling on interactive systems Other kinds of scheduling

Real-time scheduling

Page 44: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

44

Why schedule processes?

Bursts of CPU usage alternate with periods of I/O wait Some processes are CPU-bound: they don’t make many I/O

requests Other processes are I/O-bound and make many kernel

requests

CPU bound

I/O bound

Long CPU bursts Wait for I/O

Total CPU usage

Total CPU usage

Time

Short CPU bursts

Page 45: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

45

When are processes scheduled?

At the time they enter the system Common in batch systems Two types of batch scheduling

Submission of a new job causes the scheduler to run Scheduling only done when a job voluntarily gives up the CPU

(i.e., while waiting for an I/O request) At relatively fixed intervals (clock interrupts)

Necessary for interactive systems May also be used for batch systems Scheduling algorithms at each interrupt, and picks the next

process from the pool of “ready” processes

Page 46: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

46

Scheduling goals

All systems Fairness: give each process a fair share of the CPU Enforcement: ensure that the stated policy is carried out Balance: keep all parts of the system busy

Batch systems Throughput: maximize jobs per unit time Turnaround time: minimize time users wait for jobs CPU utilization: keep the CPU as busy as possible

Interactive systems Response time: respond quickly to users’ requests Proportionality: meet users’ expectations

Real-time systems Meet deadlines: missing deadlines is a system failure! Predictability: same type of behavior for each time slice

Page 47: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

47

Measuring scheduling performance

Throughput Amount of work completed per second (minute, hour) Higher throughput usually means better utilized system

Response time Response time is time from when a command is submitted until

results are returned Can measure average, variance, minimum, maximum, …

Turnaround time amount of time to execute a process (from delivery to execute =

waiting time for entry to memory + waiting time for entry to ready queue + run time + I/O time )

Usually not possible to optimize for all metrics with the same scheduling algorithm

Page 48: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

48

CPU Scheduler (cont.)

Short-term scheduler is invoked very frequently (milliseconds) (must be fast)

Long-term scheduler is invoked very infrequently (seconds, minutes) (may be slow)

The long-term scheduler controls the degree of multiprogramming

Page 49: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

49

CPU Scheduler

Selects from among the processes in memory that are ready to execute, and allocates the CPU to one of them

CPU scheduling decisions may take place when a process Switches from current state to new state

Page 50: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

50

Context Switch

When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process

Context-switch time is overhead; the system does no useful work while switching

Time dependent on hardware support

Page 51: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

51

Optimization Criteria

Max CPU utilizationMax throughputMin turnaround time Min waiting time Min response time

Page 52: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

52

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 Waiting time – amount of time a process has been

waiting in the ready queue 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)

Page 53: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

53

Scheduling type:

I/O Scheduling Short time scheduling

Switch Ready to Running

Long time scheduling Switch New to Ready

Mid time scheduling Switch Waiting to

Ready

Page 54: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

54

First Come, First Served (FCFS)

Goal: do jobs in the order they arrive

Fair in the same way a bank teller line is fair

Privilege: Simple algorithm! Problem: long jobs delay

every job after them Many processes may wait for a

single long job Priority is not supported

A B C D

4 3 6 3

Current job queue

Execution order

FCFS scheduler

A B C D

4 3 6 3

Page 55: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

55

Shortest Job First (SJF)

Goal: do the shortest job first

Short jobs complete first Long jobs delay every job

after them Jobs sorted in increasing

order of execution time Ordering of ties doesn’t

matter Shortest Remaining Time

First (SRTF): preemptive form of SJF

Problem: how does the scheduler know how long a job will take?

A B C D

4 3 6 3

AB CD

43 63

Current job queue

Execution order

SJF scheduler

Commensurate with Batch Systems

Page 56: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

56

Three-level scheduling

CPU

Mainmemory

CPU scheduler

Memoryscheduler

Admissionscheduler

Inputqueue

Arrivingjobs

Jobs held in input queue until moved into memory Pick “complementary jobs”: small & large, CPU- & I/O-intensive Jobs move into memory when admitted

CPU scheduler picks next job to run Memory scheduler picks some jobs from main memory and

moves them to disk if insufficient memory space

Commensurate with Batch Systems

Page 57: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

57

Round Robin (RR) scheduling

Round Robin scheduling Give each process a fixed Time

Slice (quantum) Rotate through “ready” processes Each process makes some progress

What’s a good quantum? Too short: many process switches

hurt efficiency Too long: poor response to

interactive requests Typical length: 10–50 ms

A B C D E

Time

ABCDE

Commensurate with Interactive Systems

Page 58: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

58

Example:

Quantum time: 20 ms Context switch time: 5 ms Overhead cost time: 5/25 = 20%

Quantum time: 100 ms Context switch time: 5 ms Overhead cost time: 5/105 < 5%

Short Quantum: Low performance Long Quantum: High performance & bad response time

Page 59: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

59

Priority scheduling

Assign a priority to each process “Ready” process with highest priority

allowed to run Running process may be interrupted

after its quantum expires Priorities may be assigned

dynamically Reduced when a process uses CPU

time Increased when a process waits for

I/O (may be set priority to 1/f, f is used time in last quantum)

Often, processes grouped into multiple queues based on priority, and run round-robin per queue

Priority 4

Priority 3

Priority 2

Priority 1

High

Low

“Ready” processes

Commensurate with Interactive Systems

Page 60: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

60

Shortest Process Next (SPN)

Run the process that will finish the soonest In interactive systems, job completion time is unknown!

Guess at completion time based on previous runs Update estimate each time the job is run Estimate is a combination of previous estimate and most

recent run time Not often used because round robin with priority

works so well!

Estimate time for interactive process:

Page 61: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

61

Feedback (FB)

Always estimated remaining time is not possible & SPN is not executable

The (long) process at first time place in RQ0

At second time place in RQ1, ...

The short process is completed fast

Page 62: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

62

Lottery scheduling

Give processes “tickets” for CPU time More tickets => higher share of CPU

Each quantum, pick a ticket at random If there are n tickets, pick a number from 1 to n Process holding the ticket gets to run for a quantum(1/n)

Over the long run, each process gets the CPU m/n of the time if the process has m of the n existing tickets

Tickets can be transferred Cooperating processes can exchange tickets Clients can transfer tickets to server so it can have a

higher priority

Page 63: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

63

Scheduling in Real-Time Systems

Schedulable real-time system Given

m periodic events event i occurs within period Pi and requires Ci seconds

Then the load can only be handled if

1

1m

i

i i

C

P

Page 64: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

64

Scheduling user-level threads

Kernel picks a process

Run-timesystem

Threadtable

Processtable

Kernel picks a process to run next

Run-time system (at user level) schedules threads

Run each thread for less than process quantum

Example: processes get 50ms each, threads get 5ms each

Example schedule:A1,A2,A3,A1,B1,B3,B2,B3

Not possible:A1,A2,B1,B2,A3,B3,A2,B1

Process A Process B

Runtime system picks a thread

Possible scheduling of user-level threads 50-msec process quantum threads run 5 msec/CPU burst

Page 65: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

65

Scheduling kernel-level threads

Kernel schedules each thread

No restrictions on ordering May be more difficult for

each process to specify priorities

Example schedule:A1,A2,A3,A1,B1,B3,B2,B3

Also possible:A1,A2,B1,B2,A3,B3,A2,B1

Process A Process B

Kernel picks a thread

Threadtable

Processtable

Page 66: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Interprocess communication

Mehdi [email protected]

Spring 1386

Page 67: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

67

Inter Process Communication (IPC)

Mechanism for processes to communicate and to synchronize their actions

Message system – processes communicate with each other without resorting to shared variables

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

Implementation of communication link physical (e.g., shared memory, hardware bus, network) logical (e.g., logical properties)

Page 68: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

68

Communications Models

a) Indirect Communication b) Direct Communication

Page 69: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

69

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 communication link Links are established automatically A link is associated with exactly one pair of communicating

processes Between each pair there exists exactly one link The link may be unidirectional, but is usually bidirectional

Page 70: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

70

Indirect Communication

Messages are directed and received from mailboxes (also referred to as ports) Each mailbox has a unique id Processes can communicate only if they share a

mailbox Properties of communication link

Link established only if processes share a common mailbox

A link may be associated with many processes Each pair of processes may share several

communication links Link may be unidirectional or bidirectional

Page 71: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

71

Indirect Communication (cont.)

Operations create a new mailbox send and receive messages through mailbox destroy a mailbox

Primitives are defined as:send(A, message) – send a message to mailbox Areceive(A, message) – receive a message from mailbox A

Page 72: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

72

Indirect Communication (cont.)

Mailbox sharing P1, P2, and P3 share mailbox A P1 sends; P2 and P3 receive Who gets the message?

Solutions Allow a link to be associated with at most two processes Allow only one process at a time to execute a receive

operation Allow the system to select arbitrarily the receiver. Sender

is notified who the receiver was.

Page 73: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

73

Synchronization

Message passing may be either blocking or non-blocking

Blocking is considered synchronous Blocking send has the sender block until the message is

received Blocking receive has the receiver block until a message is

available Non-blocking is considered asynchronous

Non-blocking send has the sender send the message and continue

Non-blocking receive has the receiver receive a valid message or null

Page 74: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

74

Buffering

Queue of messages attached to the link; implemented in one of three ways:

1. Zero capacity – 0 messagesSender must wait for receiver (rendezvous)

2. Bounded capacity – finite length of n messagesSender must wait if link full

3. Unbounded capacity – infinite length Sender never waits

Page 75: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

75

Client-Server Communication

Sockets The Berkeley Unix mechanism for creating a virtual connection

between processes. Sockets interface Unix's standard I/O with its network communication facilities

Remote Procedure Calls RPC A protocol which allows a program running on one host to cause

code to be executed on another host without the programmer needing to explicitly code for this. RPC is an easy and popular paradigm for implementing the client-server model of distributed computing

Remote Method Invocation (Java) RMI Part of the Java programming language library which enables a

Java program running on one computer to access the objects and methods of another Java program running on a different computer in a distributed network

Page 76: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

76

Sockets

A socket is defined as an end point for communication

Concatenation of IP address and port

The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8

Communication consists between a pair of sockets

Page 77: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

77

Socket Communication

Page 78: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

78

Remote Procedure Calls

Remote procedure call (RPC) abstracts procedure calls between processes on networked systems.

Stubs – client-side proxy for the actual procedure on the server. Stub: A local procedure in a remote procedure call. The client calls the stub to

perform some task and need not necessarily be aware that RPC is involved. The stub transmits parameters over the network to the server and returns the results to the caller

The client-side stub locates the server and marshalls the parameters. Marshalling: The process of packing one or more items of data into a message

buffer, prior to transmitting that message buffer over a communication channel. The packing process not only collects together values which may be stored in non-consecutive memory locations but also converts data of different types into a standard representation agreed with the recipient of the message

The server-side stub receives this message, unpacks the marshalled parameters, and peforms the procedure on the server.

Page 79: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

79

Marshalling Parameters

Page 80: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

80

Execution of RPC

Page 81: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

81

Remote Method Invocation

Remote Method Invocation (RMI) is a Java mechanism similar to RPCs.

RMI allows a Java program on one machine to invoke a method on a remote object.

Page 82: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

Classical IPC problems

Mehdi [email protected]

Spring 1386

Race Conditions

Page 83: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

83

Race Conditions

Two processes want to access shared memory at same time

Page 84: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

84

Race Conditions

A.in= in (7) Interrupt B.in= in (7) Spoller[B.in]=BFileName Spoller[7] In=B.in+1 (8) Spoller[A.in]=AFileName Spoller[7] In:=A.in+1 (8) BFile never print!

Page 85: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

85

Critical Regions (1)

Critical Regions solution: Mutual exclusion*

Four conditions to provide mutual exclusion1. No two processes simultaneously in critical region2. No assumptions made about speeds or numbers of CPUs3. No process running outside its critical region may block another

process4. No process must wait forever to enter its critical region

*Mutual exclusion: A collection of techniques for sharing resources so that different uses do not conflict and cause unwanted interactions

Page 86: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

86

Critical Regions (2)

Mutual exclusion using critical regions

Page 87: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

87

Mutual exclusion solutions Mutual Exclusion with Busy Waiting

Interrupts disable Lock variables Strict alternation Peterson’s solution TSL instruction

Sleep and wake up Producer-consumer problem

Semaphore Producer-consumer problem with semaphore

Mutexes Monitors Message Passing

Producer-consumer problem with Message Passing

Page 88: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

88

Interrupts disable

CPU switches with interrupt When Interrupts are disable, other process are disable May be interrupt not enable & system halted! Impossible for multi processors system

Page 89: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

89

Lock variables

Lock variable idea is a software solution:

P1: while Lock!=1 do wait Lock=1 Enter to critical region Lock=0

Page 90: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

90

Strict alternation

Proposed solution to critical region problem(a) Process 0. (b) Process 1.

Page 91: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

91

Peterson’s solution (1982)

Peterson's solution for achieving mutual exclusion

Page 92: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

92

TSL instruction

Entering and leaving a critical region using the TSL instruction

Page 93: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

93

Problems of Mutual Exclusion with Busy Waiting

Busy Waiting problem (waiting loop)

Priority inversion problem P1 with Low priority & P2 with High priority If P1 in running state, CPU not switched to P2 P2 wait for enters to running state P1 waiting enters to critical region CPU never switched to P2 & P1 in waiting loop forever

Page 94: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

94

Sleep and Wakeup

Producer-consumer problem with fatal race condition

Page 95: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

95

Semaphores (Dijkstra 1965)

Define 2 operation Down & Up Down (Semaphore)

Semaphore-- if (Semaphore<0) Sleep(); /* atomic operation */ Up (Semaphore)

Semaphore++; if (Semaphore<=0) Wakeup(x) ; /* atomic operation */

Down or Wait or P (Proberen) Up or Signal or V (Verhogen)

Page 96: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

96

Semaphores implementation 

Struct semaphore {int count;queueType queue;

}

void wait(semaphore s){

disable all interrupts; /* duration of semaphore operations is several micro second */s.count--;if (s.count<0)

place this process in s.queue & block this process; enable all interrupts;

}

void signal(semaphore s){

disable all interrupts;s.count++;if (s.count<=0)

remove a process P from s.queue & place on ready list;enable all interrupts;

}

Page 97: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

97

Mutual exclusion solution with semaphores

const int n=100;semaphore s=1;void Process(int i){

while(true){

wait(s);/* critical section */signal(s);/* reminder */

}}

Page 98: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

98

Producer & Consumer solution with Semaphores

The producer-consumer problem using semaphores

Page 99: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

99

Semaphores for multi processors system

Each semaphore must be protected by lock variable

Block the bus & memory for other CPU

Use TSL instruction for access to semaphore

Page 100: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

100

Mutexes

Implementation of mutex_lock and mutex_unlock

Page 101: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

101

Monitors (Hoare 1974)

Semaphore solution is difficult Semaphore solution is low level Bug in one process, extend to other processes Monitors solution is high level solution Only one process of monitor can be active at any time If one process call a process of monitor and another

process of monitor is active, the caller is block Mutual exclusion implemented by compiler Use condition for sleep & wake up in the monitor

Page 102: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

102

Monitors model

monitor monitor_name

{ shared variable declarations

procedure p1(…) {

….

} procedure pn(…) {….}{

initialization code}

}

Page 103: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

103

Example of a monitor in pascal

Page 104: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

104

Producer-consumer problem with monitor

Outline of producer-consumer problem with monitors only one monitor procedure active at one time buffer has N slots

Page 105: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

105

Producer-consumer problem in Java

Page 106: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

106

Producer-consumer problem in Java (cont.)

Page 107: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

107

Message Passing

Inter process communication without share memory Use send & receive system call for communication send(destination,&message) receive(source,&message) If message is not exist:

Receiver is blocked until message is not reply Return error message

Page 108: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

108

Message Passing problems

Loss of the message Acknowledgement Process naming Authentication Time overhead

Page 109: Operating Systems Mehdi Naghavi naghavi@iust.ac.ir Winter 1385

109

Producer-consumer problem with N messages

The producer-consumer problem with N messages