34
CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Embed Size (px)

Citation preview

Page 1: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

CS 149: Operating SystemsFebruary 24 Class Meeting

Department of Computer ScienceSan Jose State University

Spring 2014Instructor: Ron Mak

www.cs.sjsu.edu/~mak

Page 2: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

2

Example Multithreading Program

Simulation of students visiting a professor during her office hour.

Only one student can be in the office at a time. Three chairs outside the office for waiting students. Student leaves immediately if there are no available chairs.

Written in C using the Pthreads library.

Contains a subtle threading bug! Causes a deadlock under certain circumstances. Can you find the error and correct it?

_

Demo

Page 3: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

3

Assignment #3

Create a multithreaded simulation of concert ticket sellers during one hour. 100 seats available. High-price ticket seller named H.

Requires randomly exactly 1 or 2 minutes per ticket sale. Medium-price ticket sellers named M1, M2, and M3.

Each requires randomly exactly 2, 3, or 4 minutes per sale. Low-price ticker sellers named L1, L2, L3, L4, L5, and L6.

Each requires randomly exactly 4, 5, 6, or 7 minutes per sale.

N customers per seller arrive randomly during the hour. N is a command-line parameter. For simplicity, customers arrive only at the start of a minute.

Page 4: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

4

Assignment #3, cont’d

All ten ticket sellers work collaboratively.

Each serves customers in the order they arrive in his queue. First check to see if there are still seats available.

If none, the customer leaves immediately. Take the required number of minutes to complete the sale.

Then the customer leaves. Ensure that two customers aren’t assigned to the same seat.

The concert has ten rows of ten seats each.

Ticket seller H assigns seats starting in row 1 and works back. Ticket sellers L1 - L6 assign seats starting in row 10

and work forward. Ticket sellers M1, M2, and M3 assign seats starting in row 5,

then row 6, then row 4, then row 7, etc.

Page 5: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

5

Assignment #3, cont’d

Print a line for each event that occurs: A customer arrives at the tail of a seller’s queue. A customer is served and is assigned a seat, or is told the

concert is sold out, in which case the customer immediately leaves.

A customer completes a ticket purchase and leaves.

Start each event print line with a time stamp, such as 0:05, 0:12, etc._

Page 6: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

6

Assignment #3, cont’d

After each ticket sale, also print the concert seating chart as a 10-by-10 matrix. Show which customer was assigned to each seat. Identify ticket seller H’s customers as H001, H002, H003, ... Identify the customers of ticket sellers M1, M2, …, as M101,

M102, …, M201, M202, … Identify the customers of ticket sellers L1, L2, … as L101,

L102, …, L201, L202, ... Indicate unsold seats with dashes.

At the end of the hour, or when all the tickets are sold: Each ticket seller completes any sale still in progress. Remaining customers in the queues immediately leave.

Page 7: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

7

Assignment #3, cont’d

Simulate the events that occur during one hour. 1 second real time = 1 minute simulated time. Your program should run for 60 seconds,

where each second simulates one minute. `

Write your program in C or C++ Use the Pthreads library.

Run your program for N = 5, 10, and 15 customers per ticket seller. N is a command-line parameter. At the end of each run, print how many H, M, and L customers

got seats, how many customers were turned away, etc._

Page 8: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

8

Assignment #3, cont’d

Tips Simulate each ticket seller and customer with a separate thread. Customers arrive at random times during the hour:

Each customer initially sleep randomly integer 0 – 59 seconds. Upon waking, the customer arrives at the ticket queue. A seller sleeps the appropriate random number of seconds

to simulate taking the minutes to complete a ticket sale. What are the critical regions? What process synchronization is required?

Extra credit (10 points) Impatient customers leave after waiting 10 minutes

in a ticket queue._

Page 9: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

9

Assignment #3, cont’d

Turn in a zip file containing: Your C or C++ source files. A text file containing output from your simulation runs. A 1- or 2-page report that describes your software design.

What parameters did you adjust to make the simulation run realistically?

What data was shared and what were the critical regions? What process synchronization was required? Note clearly in your report if you did the extra credit.

Important Name your zip file after your team name.

Example: SuperCoders.zip Subject line: CS 149-section Assignment #3, team name

Page 10: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

10

Deadlocks

Deadlocks, AKA the Deadly Embrace In either case, your application is hung. What happened?

Deadlocks can occur when a set of processes are contending for resources.

The sequence of events required for a process to use a resource:

1. Request the resource.

2. Use the resource.

3. Release the resource._

Page 11: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

11

Deadlocks, cont’d

Deadlocks can occur when the OS grants processes exclusive access to resources. Hardware devices (e.g., DVD reader) Memory Data

A resource is anything that can be used by only a single process at a time. A process may need to have exclusive access

to several resources at a time. Resources are preemptable and nonpreemptable.

_

Page 12: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

12

Deadlocks over Resources

Preemptable resource Can be taken away from a process that owns it. No ill effects on the process. Example: memory

Nonpreemptable resource Cannot be taken away from the process owning it

without causing the process to fail. Example: CD recorder

If a process requests a resource that is not available, then the process must wait. The OS may unblock the process

when the resource becomes available again.

Page 13: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

13

Deadlock Definition

A set of processes is deadlocked if: Each process in the set is waiting for an event. Only another process in the set can cause the event.

If all the processes are waiting, none of them can cause the event that wakes up the blocked processes._

Page 14: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

14

Deadlock Conditions

Mutual exclusion Each resource is either available or

currently assigned to exactly one process.

Hold and wait Processes currently holding resources that were

granted earlier can request new resources.

No preemption A resource previously granted to a process

cannot be forcibly taken away from the process. The process must explicitly release the resource.

Circular wait A circular chain of process, each waiting for a resource

held by another process in the chain.

Page 15: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

15

Deadlock Modeling

Resource allocation graphs Two types of nodes: processes (shown as circles) and

resources (shown as squares).

(a) Process A holds resource R. (b) Process B requests resource S. (c) A deadlock situation.

Modern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 16: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

16

Deadlock Modeling, cont’d

Process C waits for Resource T, which is held by Process D.

Process D waits for Resource U, which is held by Process C.

Deadlock cycle: C T D U C

Modern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 17: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

17

Deadlock Modeling, cont’d

Suppose we have three processes A, B, and C that are competing for resources R, S, and T. Their requests and releases:

The process scheduler is free to run any unblocked process at any instant._

Page 18: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

18

Deadlock Modeling, cont’d

One solution: The scheduler allows Process A to run to completion, then Process B, and finally Process C. No competition for resources no deadlocks. But also no parallelism.

_

Page 19: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

19

Deadlock Modeling, cont’d

What happens if we use the Round-Robin instead?

A blocks B blocks C blocksModern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 20: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

20

Deadlock Modeling, cont’d

Would a different scheduling order help?

Process Bis suspended.

What happensnow if Process Bwakes up?

Modern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 21: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

21

Pthreads Deadlock Exampleint worker1_id;int worker2_id;

void *worker1(void *param);void *worker2(void *param);

pthread_mutex_t mtx1;pthread_mutex_t mtx2;

int main(int argc, char *argv[]){ srand(time(0)); pthread_mutex_init(&mtx1, NULL); pthread_mutex_init(&mtx2, NULL); ...}

Where isthere a potential deadlocklurking in this code?

Page 22: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

22

Pthreads Deadlock Example, cont’d

...

int main(int argc, char *argv[]){ ... printf("main: Create worker 1 thread.\n"); worker1_id = 1; pthread_t worker1_tid; pthread_attr_t worker1_attr; pthread_attr_init(&worker1_attr); pthread_create(&worker1_tid, &worker1_attr, worker1, &worker1_id); printf("main: Create worker 2 thread.\n"); worker2_id = 2; pthread_t worker2_tid; pthread_attr_t worker2_attr; pthread_attr_init(&worker2_attr); pthread_create(&worker2_tid, &worker2_attr, worker2, &worker2_id);

printf("main: Wait for workers to finish.\n"); pthread_join(worker1_tid, NULL); pthread_join(worker2_tid, NULL); printf("main: Done!");}

Page 23: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

23

Pthreads Deadlock Example, cont’dvoid *worker1(void *param){ printf("Worker1: Locking mutex 1.\n"); pthread_mutex_lock(&mtx1); sleep(rand()%3); printf("Worker1: Locking mutex 2.\n"); pthread_mutex_lock(&mtx2); printf("Worker1: Working.\n"); sleep(rand()%5); printf("Worker1: Unlocking mutex 2.\n"); pthread_mutex_lock(&mtx2); sleep(rand()%3); printf("Worker1: Unlocking mutex 1.\n"); pthread_mutex_lock(&mtx1);}

Page 24: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

24

Pthreads Deadlock Example, cont’dvoid *worker2(void *param){ printf("Worker2: Locking mutex 2.\n"); pthread_mutex_lock(&mtx2); sleep(rand()%3); printf("Worker2: Locking mutex 1.\n"); pthread_mutex_lock(&mtx1); printf("Worker2: Working.\n"); sleep(rand()%5); printf("Worker2: Unlocking mutex 1.\n"); pthread_mutex_lock(&mtx1); sleep(rand()%3); printf("Worker2: Unlocking mutex 2.\n"); pthread_mutex_lock(&mtx2);} Demo

Page 25: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

25

Deadlock Strategies

1. Ignore the problem altogether.

2. Detection and recovery.

3. Avoidance by careful resource allocation.

4. Prevention by negating one of the four necessary conditions. Mutual exclusion Hold and wait No preemption Circular wait

_

Page 26: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

26

Ignore Deadlocks

Deadlocks may be unavoidable when there are limited resources.

The OS can impose draconian measures to prevent deadlocks that happen only occasionally.

If there are too many restrictions on the use of resources, the cost in inconvenience is too high.

Users may rather tolerate infrequent system lockups._

Page 27: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

27

Deadlock Detection and Recovery

The OS monitors resource requests and releases. It maintains an internal resource allocation graph. If it detects any cycles, it starts to kill processes one by one

until the cycle is broken.

The OS periodically checks to see if any processes have been continuously blocked for a long time. Kill off such processes.

_

Page 28: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

28

Deadlock Prevention

Relax mutual exclusion

Never assign a resource exclusively to a process.

Example: Instead of processes contending for the use of a printer, use spooling instead.

But not all resources can be spooled._

Mutual exclusionHold and waitNo preemptionCircular wait

Page 29: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

29

Deadlock Prevention, cont’d

Require all processes to request all their resources before starting execution.

A process waits if any one resource is unavailable. No process will hold some resources

and block waiting for others. But not all process know what resources

they need ahead of time.

Poor use of resources. Example: A process reads data from a shared tape drive,

processes the data for an hour, and writes results to the tape drive. It locks up the tape drive for an hour._

Mutual exclusionHold and waitNo preemptionCircular wait

Page 30: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

30

Deadlock Prevention, cont’d

Require that a process that requests a resource:

First release all the resources that it currently holds.

Then try to acquire all its required resources all at once._

Mutual exclusionHold and waitNo preemptionCircular wait

Page 31: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

31

Deadlock Prevention, cont’d

Forcibly take a resource awayfrom a process if a higher priorityprocess requests that resource.

Can you interrupt a print jobfor a higher priority one?_

Mutual exclusionHold and waitNo preemptionCircular wait

Page 32: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

32

Deadlock Prevention, cont’d

Allow a process only one resource at a time. Too restrictive.

Global numbering of all resources. Processes can requests all the resources they want,

but only in numerical order.

Mutual exclusionHold and waitNo preemptionCircular wait

Modern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 33: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

33

Deadlock Prevention, cont’d

Global numbering of all resources: Process A requests Resource i. Process B requests Resource j. If i > j, then process A cannot request Resource j. if i < j, then process B cannot request Resource i. Therefore, no deadlock can occur.

It may be hard to devise a workable ordering.Modern Operating Systems, 3rd ed.Andrew Tanenbaum(c) 2008 Prentice-Hall, Inc.. 0-13-600663-9All rights reserved

Page 34: CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak mak

Department of Computer ScienceSpring 2014: February 24

CS 149: Operating Systems© R. Mak

34

Deadlock Prevention, cont’d