message queues

41
Message Queues [ http://www.linux-tutorial.info/ modules.php?name=Tutorial&pagei d=292 ]

Upload: manju

Post on 22-Feb-2016

49 views

Category:

Documents


0 download

DESCRIPTION

Message Queues. [ http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=292 ] . Monitors :. Previous examples had the critical section inside the process Idea is to put the critical section inside of a construct called a monitor . - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Message Queues

Message Queues [

http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=292]

Page 2: Message Queues

Monitors: Previous examples had the critical section inside the

process Idea is to put the critical section inside of a construct

called a monitor. Monitor has entry points (like methods) BUT only

one entry call can be processed at a time. Supported in concurrent languages: Modula-2, -3,

Concurrent Pascal, Concurrent C, CSP, also, partially, Java, also part of the .NET Framework library.

Page 3: Message Queues

Generic outline:

Monitor monitor_name:monitor variables:

entry entry1;::

end entryentry entry2

::

end entry;:

etc;:

end Monitor;

Page 4: Message Queues

If proc1 is executing in a monitor entry and proc2 calls an entry then proc2 waits until proc1 finishes.

A monitor has two condition variables – special variables that define wait and wakeup protocols. i.e. Suppose x is a condition variable. x.wait forces a process to wait x.signal wakes a process in a wait state because of an

x.wait.

Page 5: Message Queues

Bounded Buffer problem:Monitor buffMgmt

int first=0, last=0, occupied=0, N // monitor variablesint [N] buffercondition empty, full; // condition variables

entry putin(x);if (occupied == N)

full.waitbuffer[first] = xfirst = (first+1) % N;occupied++empty.signal

end putinentry getout()

data temp;if (occupied == 0)

empty.waittemp = buffer(last);last = (last + 1) % Noccupied--full.signalreturn temp

end

Page 6: Message Queues

Do a Monitor solution to the readers and writers problem

Recall the conditions to the R/W problem: If a reader wants access, deny iff a writer is active if a writer wants access, deny only iff a reader or

writer is active Note: this could cause starvation of writers if there are

many readers Could replace 1 above with: if a reader wants access,

deny iff a writer is active or a writer is waiting.

Page 7: Message Queues

Monitor readers_writersint count //number of readerscondition readallowed, writeallowedboolean writingdata shared

entry startwriteif (count != 0) or (writing)

writeallowed.waitwriting = true

end entryentry donewriting

writing = falseif (Q for readallowed not empty)

readallowed.signalelse

writeallowed.signalend entryentry startread

if writing or (Q for writeallowed not empty)readallowed.wait

count++readallowed.signal

end entryentry donereading

count—if count == 0

writeallowed.signalend entry

Page 8: Message Queues

Now look at the Java implementation of the readers and writers problem. It’s a little different.

Page 9: Message Queues

Ada [http://www.acm.org/sigs/sigada] [http://www.adaic.org/] [http://www.adaic.org/atwork/index.html] The language is named after Ada Byron, Countess

of Lovelace, who was the first published computer programmer and daughter of the poet Lord Byron.

All previous solutions were centralized. Ada is more of a distributed/network solution.

Page 10: Message Queues

Controls computers in nearly all new aircraft Nearly all air traffic control systems hi-speed railroads and urban subway systems electronic funds and banking communication and navigation satellites. Steel mills, industrial robots, medical electronics,

telecommunications

Page 11: Message Queues

Two types of tasks: caller: calls entry points in a server server: may (or may not) accept calls

calls not processeduntil accept has been issued. called a rendezvous.

Page 12: Message Queues

Ada can be used to simulate a semaphore.

procedure mutexc istask semaphore is

entry waitentry signal

end semaphoretask body semaphore is

beginloop

accept wait

accept signalend loop

end semaphore

task Pi

task body Pi isbegin

loop::

wait

critical sectionsignal

::end loop

end Pi

Page 13: Message Queues

Select statementSelect

when cond1 => accept entry1do stuff

end entryor when cond2 => accept entry2

do stuffend entryor when ……..

::

elsedo stuff

end select

Page 14: Message Queues

Each condition is a guard and evaluates to T or F. Several may be true an accept for which the corresponding guard is True

is open. An open accept is chosen arbitrarily (not by Ada)

from the list of open accepts for which entry calls have been made.

The chosen accept is then processed. No such accepts => the else option is taken

Page 15: Message Queues

Ada Solution to the readers and writers problem

task readertask body reader isbegin

loop::

startread

read stufffinishread

::end loop

end reader

task writertask body writer

somedata : anytypebegin

loop::

writeshared(x)::end loop

end writer

Page 16: Message Queues

task readerswriters isentry startreadentry finishreadentry writetoshared

end;task body readerswriters is

numreaders : Integerbegin

numreaders = 0loop

selectwhen writetoshared’count = 0

accept startreadnumreaders = numreaders + 1

end startreador

accept finishreadnumreaders = numreaders – 1

end finishreador

when numreaders = 0accept writeshared(x : anytype)

write x to shared areaend writeshared

end selectend loop

end

Page 17: Message Queues

Review of concurrency constructs Program critical sections, software implementations semaphores monitor Java Synchronized methods ada

Page 18: Message Queues

Deadlock Definition: Deadlock (also deadly embrace) occurs

when two or more processes in a wait state are each waiting for a resource held by one of the other processes in the wait state.

Ex: Previously failed attempts at mutual exclusion processes write to a shared buffer, filling it. If buffer hits

limit before processes are done, deadlock occurs. Database examples if two apps each hold a record and

want what the other has.

Page 19: Message Queues

Four necessary conditions for deadlock to occur: Mutual Exclusion

process claims exclusive control of required resource. Hold and Wait

process holds allocated resources while requesting more. No preemption

Resources cannot be taken away until process is finished with them.

Circular wait Circular chain of processes exist in which each process

holds at least 1 resource requested by the next process in the chain.

Page 20: Message Queues

Four areas of deadlock study: Prevention

Create an environment where deadlock is impossible. Avoidance

Use algorithms to monitor resource allocation so that deadlock won’t happen.

Detection Determine when deadlock has occurred.

Recovery What to do when deadlock occurs.

Page 21: Message Queues

Handling Deadlocks: Implement a protocol to prevent or avoid deadlocks. Allow deadlocks to occur, then detect and recover. Ignore and leave it to the user. Third option is most common (Linux and Windows

use this).

Page 22: Message Queues

Prevention Eliminate one of the previously mentioned necessary

conditions, but which one? Mutual Exclusion?

Can generate incorrect results. Hold and Wait?

Could require processes to request and get all resources at the same time. Thus, can’t hold resources while requesting more. Not always practical. Resources may be held much earlier than needed.

Page 23: Message Queues

No Preemption? Take resources away might result in loss of work. Process

will have to be restarted. Circular Wait?

Request resources in some numerical order? Awkward May not be the order in which they are needed.

Page 24: Message Queues

Conclusion Prevention is not practical or at least cannot be done

without severe side effects.

Page 25: Message Queues

Detection Resource allocation graph example.

Specifies which process is waiting for what resource (request edge) and what resource is allocated to which process (assignment edge). Example below:

RiPj means resource Ri is allocated to process Pj Pj Ri means process Pj is waiting for a resource of type Ri

Page 26: Message Queues

No cycle no deadlock. Cycle deadlock possible. If each resource group contains just one resource

then cycle deadlock. Need cycle detection algorithms of COMP SCI 242

Page 27: Message Queues

Deadlock avoidance algorithms

Page 28: Message Queues

Resource Allocation Graph Algorithm: Add a claim edge (dotted line in graph on the next

slide) to the graph. Represents that a process may request a resource.

Process makes a request claim edge converted to a request edge or assignment edge, depending on whether the resource was allocated.

Safe state no cycles in the graph. Unsafe state a cycle exists (NOTE: does NOT

mean deadlock exists – only that it could happen.

Page 29: Message Queues

Above case is safe: P1 or P2 can finish. If P2 requests R1, convert the claim edge to a request edge.

P2 is now waiting but the system is still safe since P1 can still finish and release the R1 resource. OS has little to do here. The request is made.

However, if instead P3 requests R2, it can be allocated but then a cycle exists and the system is unsafe. Thus, although R2 could be allocated, it is not. NOTE: Deadlock has not occurred but it could if P1 and P3 assert their claims.

P1P2 P3

R1R2

R3

Page 30: Message Queues

Banker’s Algorithm Applicable where there are multiple resources of a

common type. Processes request 1 or more resources of a type, but don’t care which they get.

Each process declares the maximum number of resources of each type it needs.

Distinguishes between a safe and an unsafe state.

Page 31: Message Queues

Safe state: Resource situation is such that all existing processes can finish, regardless of future requests.

Unsafe state: It’s possible that a sequence of requests could deadlock the system – even if requests are denied. Deadlock may occur.

Goal: No request should cause the system to change from a safe to unsafe state.

Page 32: Message Queues

Data Structures: Available[i] – number of available resources

of type Ri. Max[i] [j] – contains the maximum number of

resources Pi can request of type Rj. Allocation[i] [j] – contains the number of

resources of type Rj allocated to Pi. Need[i] [j] = Max[i] [j] – Allocation[i] [j]

Page 33: Message Queues

Safety algorithm: Initialize Work[j] = Available[j] for all j=1 to #resource types

and Finish[i] = false for all i=1 to #processes Find an i where Finish[i] is false and Need[i] <= Work. i.e.

find a process whose need for each type is less than the # available for that type. NOTE: Need[i] and Work are both vectors and <= means that the inequality holds for ALL elements in the vector. Do step 4.

Work=Work+Allocation and Finish[i]=true. Repeat from Step 2.

If Finish[i] is True for all i, the system is safe. Else an unsafe state.

Page 34: Message Queues

Examples:

AllocationMax Available

A B C A B C A B C

P0 0 1 0 7 5 3 3 3 2

P1 2 0 0 3 2 2

P2 3 0 2 9 0 2

P3 2 1 1 2 2 2

P4 0 0 2 4 3 3

Page 35: Message Queues

Initially: Work = (3, 3, 2) Step 1: Could use i=1 (Need=(1, 2, 2)) or

i=3 (Need=0, 1, 1)). Choose i=3. Work=(5, 4, 3)

Step 2: Use i=1. Work=(7, 4, 3) Step 3: Use i=0. Work=(7, 5, 3) Step 4: Use i=4. Work=7, 5, 5) Step 5: Use i=2. Work=(10, 5, 7) -----SAFE

Page 36: Message Queues

Suppose P1 requests one resource of type A and 2 of type C. If request > Available, the request must be denied. Otherwise, simulate the granting of this request and check resulting state. Granting this request would result in

Allocation Max Available

A B C A B C A B C

P0 0 1 0 7 5 3 2 3 0

P1 3 0 2 3 2 2

P2 3 0 2 9 0 2

P3 2 1 1 2 2 2

P4 0 0 2 4 3 3

Page 37: Message Queues

Initially: Work = (2, 3, 0) Step 1: Use i=1. Work=(5, 3, 2) Step 2: Use i=3. Work=(7, 4, 3) Step 3: Use i=4. Work=(7, 4, 5) Step 4: Use i=0. Work=(7, 5, 5) Step 5. Use i=2. Work=(10, 5, 7)-----SAFE.

Grant request.

Page 38: Message Queues

What if original table looked like this?Allocation Max Available

A B C A B C A B C

P0 0 1 2 6 4 3 1 2 2

P1 2 0 0 3 2 2

P2 3 1 0 7 4 6

P3 2 1 1 2 2 2

P4 0 0 2 4 3 3

Page 39: Message Queues

Initially Work=(1, 2, 2) Step 1: Process 1 Need = (1, 2, 2). Change Work to

(3, 2, 2) Step 2: Process 3 Need = (0, 1, 1). Change Work to

(5, 3, 3) Step 3. Process 4 Need = (4, 3, 1). Change Work to

(5, 3, 5). Process 0 Need = (6, 3, 1) and Process 2 Need = (4, 3, 6) ---- at this point, cannot continue ---UNSAFE

Page 40: Message Queues

RAG algorithm: does not generalize well but more efficient.

Banker’s algorithm: generalizes better (multiple resources of the same type) but less efficient.

Page 41: Message Queues

Deadlock Recovery: Kill one of the processes – usually determined

by a priority.