slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
主講人:虞台文 PowerPoint Presentation
Download Presentation
主講人:虞台文

Loading in 2 Seconds...

play fullscreen
1 / 80

主講人:虞台文 - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

Operating Systems Principles Process Management and Coordination Lecture 2: Processes and Their Interaction. 主講人:虞台文. Content. The Process Notion Defining and Instantiating Processes Precedence Relations Implicit Process Creation Dynamic Creation With fork And join

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '主講人:虞台文' - norina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction

主講人:虞台文

content
Content
  • The Process Notion
  • Defining and Instantiating Processes
    • Precedence Relations
    • Implicit Process Creation
    • Dynamic Creation With fork And join
    • Explicit Process Declarations
  • Basic Process Interactions
    • Competition: The Critical Problem
    • Cooperation
  • Semaphores
    • Semaphore Operations and Data
    • Mutual Exclusion
    • Producer/Consumer Situations
  • Event Synchronization
slide3

Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction

The Process Notion

what is a process
What is a process?
  • A process is a program in execution.
    • Also, called a task.
  • It includes
    • Program itself (i.e., code or text)
    • Data
    • a thread of execution (possibly several threads)
    • Resources (such as files)
    • Execution info (process relation information kept by OS)
  • Multiple processes are simultaneously existent in a system.
virtualization
Virtualization
  • Conceptually,
    • each process has its own CPU and main memory;
    • processes are running concurrently.
  • Many computers are equipped with a single CPU.
  • To achieve concurrency, the followings are needed
    • CPU sharing  to virtualize the CPU
    • Virtual memory  to virtualize the memory
  • Usually done by the kernel of OS
    • Each process may be viewed in isolation.
    • The kernel provides few simple primitives for process interaction.
physical logical concurrencies
Physical/Logical Concurrencies
  • An OS must handle a high degree of parallelism.
  • Physical concurrency
    • Multiple CPUs or Processors required
  • Logical concurrency
    • Time-share CPU
interaction among processes
Interaction among Processes
  • The OS and users applications are viewed as a collection of processes, all running concurrently.
  • These processes
    • almost operate independently of one another;
    • cooperate by sharing memory or by sending messages and synchronization signals to each other; and
    • compete for resources.
why use process structure
Why Use Process Structure?
  • Hardware-independent solutions
    • Processes cooperate and compete correctly, regardless of the number of CPUs
  • Structuring mechanism
    • Tasks are isolated with well-defined interfaces
slide9

Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction

Defining and Instantiating Processes

a process flow graph
A Process Flow Graph

User session at a workstation

serial and parallel processes

serial

parallel

S/P Notation:

execution of process p1 through pn.

Serial and Parallel Processes

Serial

Parallel

properly nested process flow graphs

serial

parallel

S/P Notation:

execution of process p1 through pn.

Properly Nested Process Flow Graphs

A process flow graph is properly nested if it can be described by the functions S and P, and only function composition.

Properly

Nested

properly nested process flow graphs1
Properly Nested Process Flow Graphs

improperly

Nested

Properly

Nested

example evaluation of arithmetic expressions
Example:Evaluation of Arithmetic Expressions

Expression tree

Process flow graph

implicit process creation
Implicit Process Creation
  • Processes are created dynamically using language constructs
    • no process declaration.
  • cobegin/coend
    • syntax:

cobeginC1//C2// … //Cncoend

    • meaning:
      • All Ci may proceed concurrently
      • When allterminate, the statement following cobegin/coend continues.
implicit process creation1
Implicit Process Creation

C1;C2;C3;C4;

cobeginC1//C2//C3//Cncoend

example use of cobegin coend
Example: Use of cobegin/coend

Initialize;

cobegin

Time_Date //

Mail //

Edit;

cobegin

Complile; Load; Execute //

Edit;

cobegin

Print //

Web

coend

coend

coend;

Terminate

User session

at a workstation

data parallelism
Data Parallelism
  • Same code is applied to different data
  • The forall statement
    • syntax:

forall (parameters) statements

    • Meaning:
      • Parameters specify set of data items
      • Statements are executed for each item concurrently
example matrix multiplication
Example: Matrix Multiplication
  • Each inner product is computed sequentially
  • All inner products are computed in parallel
  • forall ( i:1..n, j:1..m ){
  • A[i][j] = 0;
  • for ( k=1; k<=r; ++k )
  • A[i][j] = A[i][j] + B[i][k]*C[k][j];
  • }
explicit process creation

explicit process creation

Explicit Process Creation
  • cobegin/coend
    • limited to properly nested graphs
  • forall
    • limited to data parallelism
  • fork/join
    • can express arbitrary functional parallelism

implicit

process creation

the fork join quit primitives
The fork/join/quit primitives
  • Syntax: forkx
  • Meaning:
    • create new process that begins executing at label x
  • Syntax: joint,y
  • Meaning: t = t–1;

if (t==0) goto y;

    • The operation must be indivisible. (Why?)
  • Syntax: quit
  • Meaning:
    • Process termination
example
Example

Synchronization needed here.

Use down-counter t1=2 and t2=3 for synchronization.

t1

t2

example1

The starting point of process pi has label Li.

Example
  • t1 = 2; t2 = 3;
  • L1: p1; fork L2; fork L5; fork L7; quit;
  • L2: p2; fork L3; fork L4; quit;
  • L5: p5; join t1,L6; quit;
  • L7: p7; join t2,L8; quit;
  • L4: p4; join t1,L6; quit;
  • L3: p3; join t2,L8; quit;
  • L6: p6; join t2,L8; quit;
  • L8: p8; quit;

t1

t2

the unix fork
The Unix fork

procid = fork();

if (procid==0)

do_child_processing

else

do_parent_processing

the unix fork1

Replicates calling process.

  • Parent and child are identical
  • except for the value of procid.
The Unix fork

Use procid to

diverge parent and child.

procid = fork();

if (procid==0)

do_child_processing

else

do_parent_processing

explicit process declarations
Explicit Process Declarations
  • Designate piece of code as a unit of execution
    • Facilitates program structuring
  • Instantiate:
    • Statically (like cobegin) or
    • Dynamically (like fork)
explicit process declarations1
Explicit Process Declarations

Syntax:

process p {

declarations_for_p;

executable_code_for_p;

};

process type p {

declarations_for_p;

executable_code_for_p;

};

example explicit process declarations
Example:Explicit Process Declarations

process p{

process p1{

declarations_for_p1;

executable_code_for_p1;

}

processtype p2{

declarations_for_p2;

executable_code_for_p2;

}

other_declaration_for_p ;

...

q = new p2;

...

}

declarations_for_p;

executable_code_for_p;

example explicit process declarations1

similar to

fork

Example:Explicit Process Declarations

process p{

process p1{

declarations_for_p1;

executable_code_for_p1;

}

processtype p2{

declarations_for_p2;

executable_code_for_p2;

}

other_declaration_for_p ;

...

q = new p2;

...

}

similar to

cobegin/coend

slide30

Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction

Basic Process Interactions

competition and cooperation
Competition and Cooperation
  • Competition
    • Processes compete for resources
    • Each process could exist without the other
  • Cooperation
    • Each process aware of the other
    • Processes Synchronization
    • Exchange information with one another
      • Share memory
      • Message passing
resource competition
Resource Competition

Shared source, e.g.,

common data

resource competition1
Resource Competition
  • When several process may asynchronously access a common data area, it is necessary to protect the data from simultaneous change by two or more processes.
  • If not, the updated area may be left in an inconsistent state.
example2
Example

x = 0;

cobegin

p1: ...

x = x + 1;

...

//

p2: ...

x = x + 1;

...

coend

What value of x should be after both processes execute?

example3

R1 = 0

R1 = 1

x = 1

R2 = 1

R2 = 2

x = 2

Example

p1: . . .

R1 = x;

R1 = R1 + 1;

x = R1;

. . .

p2: . . .

R2 = x;

R2 = R2 + 1;

x = R2;

. . .

example4

R1 = 0

R1 = 1

R2 = 0

x = 1

R2 = 1

x = 1

Example

p1: . . .

R1 = x;

R1 = R1 + 1;

x = R1;

. . .

p2: . . .

R2 = x;

R2 = R2 + 1;

x = R2;

. . .

the critical section cs
The Critical Section (CS)
  • Any section of code involved in reading and writing a share data area is called a critical section.
  • Mutual Exclusion At most one process is allowed to enter critical section.
the critical problem

cobegin

  • p1: while(1) {CS1; program1;}
  • //
  • p2: while(1) {CS2; program2;}
  • //
  • ...
  • //
  • pn: while(1) {CSn; programn;}
  • coend
The Critical Problem
  • Guarantee mutual exclusion: At any time, at most one process executing within its CSi.
the critical problem1
The Critical Problem
  • Guarantee mutual exclusion: At any time, at most one process executing within its CSi.
  • In addition, we need to preventmutual blocking:
    • Process outside of its CS must not prevent other processes from entering its CS. (No “dog in manger”)
    • Process must not be able to repeatedly reenter its CS and starve other processes (fairness)
    • Processes must not block each other forever (deadlock)
    • Processes must not repeatedly yield to each other (“after you”--“after you” livelock)
software solutions
Software Solutions
  • Solve the problem without taking advantage of special machine instructions and other hardware.
algorithm 1
Algorithm 1
  • int turn = 1;
  • cobegin
  • p1: while (1) {
  • while (turn==2); /*wait*/
  • CS1;
  • turn = 2;
  • program1;
  • }
  • //
  • p2: while (1) {
  • while (turn==1); /*wait*/
  • CS2;
  • turn = 1;
  • program2;
  • }
  • coend
algorithm 11
Algorithm 1
  • int turn = 1;
  • cobegin
  • p1: while (1) {
  • while (turn==2); /*wait*/
  • CS1;
  • turn = 2;
  • program1;
  • }
  • //
  • p2: while (1) {
  • while (turn==1); /*wait*/
  • CS2;
  • turn = 1;
  • program2;
  • }
  • coend

  • Mutual Exclusion
  • No mutual blocking
    • No dog in manger
    • Fairness
    • No deadlock
    • No livelock

What happens if p1 fail?

algorithm 2
Algorithm 2
  • int c1 = 0, c2 = 0;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • while (c2); /*wait*/
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • while (c1); /*wait*/
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • coend
algorithm 21
Algorithm 2
  • int c1 = 0, c2 = 0;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • while (c2); /*wait*/
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • while (c1); /*wait*/
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • coend

  • Mutual Exclusion
  • No mutual blocking
    • No dog in manger
    • Fairness
    • No deadlock
    • No livelock

What happens if

c1=1 and c2=1?

algorithm 3
Algorithm 3
  • int c1 = 0, c2 = 0;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • if (c2) c1=0;
  • else{
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • if (c1) c2=0;
  • else{
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • }
  • coend
algorithm 31
Algorithm 3
  • int c1 = 0, c2 = 0;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • if (c2) c1=0;
  • else{
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • if (c1) c2=0;
  • else{
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • }
  • coend

  • Mutual Exclusion
  • No mutual blocking
    • No dog in manger
    • Fairness
    • No deadlock
    • No livelock

When timing is critical, fairness and livelock requirements may be violated.

algorithm 32
Algorithm 3
  • p1: while (1) {
  • c1 = 1;
  • if (c2) c1=0;
  • else{
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • }
  • p2: while (1) {
  • c2 = 1;
  • if (c1) c2=0;
  • else{
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • }

May violate the fairness requirement.

algorithm 33
Algorithm 3
  • p1: while (1) {
  • c1 = 1;
  • if (c2) c1=0;
  • else{
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • }
  • p2: while (1) {
  • c2 = 1;
  • if (c1) c2=0;
  • else{
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • }

May violate the livelock requirement.

algorithm 4 peterson
Algorithm 4(Peterson)
  • int c1 = 0, c2 = 0, WillWait;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • willWait = 1;
  • while (c2 && (WillWait==1)); /*wait*/
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • willWait = 2;
  • while (c1 && (WillWait==2)); /*wait*/
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • coend
algorithm 4 peterson1
Algorithm 4(Peterson)

  • int c1 = 0, c2 = 0, WillWait;
  • cobegin
  • p1: while (1) {
  • c1 = 1;
  • willWait = 1;
  • while (c2 && (WillWait==1)); /*wait*/
  • CS1;
  • c1 = 0;
  • program1;
  • }
  • //
  • p2: while (1) {
  • c2 = 1;
  • willWait = 2;
  • while (c1 && (WillWait==2)); /*wait*/
  • CS2;
  • c2 = 0;
  • program2;
  • }
  • coend
  • Mutual Exclusion
  • No mutual blocking
    • No dog in manger
    • Fairness
    • No deadlock
    • No livelock

cooperation producer consumer
Cooperation: Producer/Consumer

Producer

Buffer

Consumer

Remove

Deposit

Producer must notoverwrite any data before the Consumer can remove it.

Consumer must be able to wait for the Producer when the latter falls behind and does not fill the buffer on time.

competition and cooperation1
Competition and Cooperation
  • Problems with software solutions:
    • Difficult to program and to verify
    • Competition and cooperation use entirely different solutions
    • Processes loop while waiting (busy-wait)
process states

time-out

ready_queue

dispatch

Process States

running

running

ready

ready

process states1

time-out

ready_queue

dispatch

wait(si)

wait-queues

. . .

s1

sn

. . .

. . .

Process States

running

running

ready

ready

blocked

process states2

time-out

ready_queue

dispatch

wait(si)

wait-queues

. . .

s1

sn

. . .

. . .

Process States

running

ready

ready

blocked

process states3

time-out

ready_queue

dispatch

wait(si)

signal(si)

wait-queues

. . .

s1

sn

. . .

. . .

A running process calls signal(si).

Process States

running

running

ready

ready

blocked

p v operators

time-out

ready_queue

dispatch

wait(si)

signal(si)

wait-queues

. . .

s1

sn

. . .

. . .

P/V Operators

running

running

ready

ready

P operation

V operation

blocked

dijkstra s semaphores
Dijkstra’s Semaphores
  • Dijkstra’s (1968) introduced two new operations, called P and V, that considerably simplify the coordination of concurrent processes.
    • Universally applicable to competition and cooperation among any number of processes.
    • Avoid the performance degradation resulting from waiting.
semaphores

s

There is a wait-queue associated with each semaphore.

Semaphores
  • A semaphore s is an non-negative integer, a down counter, with two operations P and V.
  • P and V are indivisible operations (atomic)

P(s)/* wait(s) */

{

if (s>0) s--;

else{

queue the process on s,

change its state to blocked,

schedule another process

}

}

V(s)/* signal(s) */

{

if (s==0 && queue is not empty){

pick a process from the queue on s,

change its state from blocked to ready;

}

else s++;

}

semaphores1

Process 1

Process 2

Process 3

Process 4

s

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores2

Process 1

Process 2

Process 3

Process 4

s

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores3

Process 1

Process 2

Process 3

Process 4

s

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program2

Program3

Program4

semaphores4

Process 1

Process 2

Process 3

Process 4

s

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores5

Process 1

Process 2

Process 3

Process 4

s

Process 3

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

Program4

semaphores6

Process 1

Process 2

Process 3

Process 4

s

Process 3

Process 3

Process 4

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores7

Process 1

Process 2

Process 3

Process 4

s

Process 3

Process 4

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores8

Process 1

Process 2

Process 3

Process 4

s

Process 3

Process 4

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores9

Process 1

Process 2

Process 3

Process 4

s

Process 4

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores10

Process 1

Process 2

Process 3

Process 4

s

Process 4

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores11

Process 1

Process 2

Process 3

Process 4

s

s

There is a wait-queue associated with each semaphore.

Semaphores

P(s)

P(s)

P(s)

P(s)

CS4

CS1

CS2

CS3

CS4

V(s)

V(s)

V(s)

V(s)

V(s)

V(s)

Program1

Program2

Program3

Program4

semaphores12

s

There is a wait-queue associated with each semaphore.

Semaphores
  • A semaphore s is an non-negative integer with two operations P and V.
  • P and V are indivisible operations (atomic)

P(s)/* wait(s) */

{

if (s>0) s--;

else{

queue the process on s,

change its state to blocked,

schedule another process

}

}

V(s)/* signal(s) */

{

if (s==0 && queue is not empty){

pick a process from the queue on s,

change its state from blocked to ready;

}

else s++;

}

mutual exclusion with semaphores
Mutual Exclusion with Semaphores

semaphore mutex = 1; /* binary semaphore */

cobegin

p1: while (1) { P(mutex); CS1; V(mutex); program1; }

//

p2: while (1) { P(mutex); CS2; V(mutex); program2; }

//

.

.

.

//

pn: while (1) { P(mutex); CSn; V(mutex); programn; }

coend;

producer consumer with semaphores
Producer/Consumer with Semaphores

// counting semaphore

semaphore s = 0; /* zero item produced */

cobegin

p1: ...

P(s); /* wait for signal from other process if needed */

...

//

p2: ...

V(s); /* send signal to wakeup an idle process*/

...

coend;

Consumer

Producer

producer consumer with semaphores1
Producer/Consumer with Semaphores

// counting semaphore

semaphore s = 0; /* zero item produced */

cobegin

p1: ...

P(s); /* wait for signal from other process if needed */

...

//

p2: ...

V(s); /* send signal to wakeup an idle process*/

...

coend;

the bounded buffer problem

e: the number of empty cells

f: the number of items available

b: mutual exclusion

The Bounded Buffer Problem

semaphore e = n, f = 0, b = 1;

cobegin

Producer: while (1) {

Produce_next_record;

P(e); /* wait if zero cell empty */

P(b); /* mutually excusive on access the buffer */

Add_to_buf;

V(b); /* release the buffer */

V(f); /* signal data available */

}

//

Consumer: while (1) {

P(f); /* wait if data not available */

P(b); /* mutually excusive on access the buffer */

Take_from_buf;

V(b); /* release the buffer */

V(e); /* signal empty cell available*/

Process_record;

}

coend

slide77

Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Process and Their Interaction

Event Synchronization

events
Events
  • An event denotes some change in the state of the system that is of interest to a process.
  • Usually principally through hardware interrupts and traps, either directly or indirectly.
two type of events
Two Type of Events
  • Synchronous event (e.g. I/O completion)
    • Process waits for it explicitly
    • Constructs: E.wait, E.post
  • Asynchronous event (e.g. arithmetic error)
    • Process provides event handler
    • Invoked whenever event is posted
case study windows 2000
Case study: Windows 2000
  • WaitForSingleObject
  • WaitForMultipleObjects

Process blocks until

object is signaled