主講人：虞台文

1. Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction 主講人：虞台文

2. 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

3. Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction The Process Notion

4. 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.

5. 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.

6. Physical/Logical Concurrencies • An OS must handle a high degree of parallelism. • Physical concurrency • Multiple CPUs or Processors required • Logical concurrency • Time-share CPU

7. 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.

8. 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

9. Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction Defining and Instantiating Processes

10. A Process Flow Graph User session at a workstation

11. serial parallel S/P Notation: execution of process p1 through pn. Serial and Parallel Processes Serial Parallel

12. 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

13. Properly Nested Process Flow Graphs improperly Nested Properly Nested

14. Example:Evaluation of Arithmetic Expressions Expression tree Process flow graph

15. 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.

16. Implicit Process Creation C1;C2;C3;C4; cobeginC1//C2//C3//Cncoend

17. 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

18. 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

19. 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]; • }

20. 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

21. 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

22. Example Synchronization needed here. Use down-counter t1=2 and t2=3 for synchronization. t1 t2

23. 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

24. The Unix fork procid = fork(); if (procid==0) do_child_processing else do_parent_processing

25. 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

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

27. Explicit Process Declarations Syntax: process p { declarations_for_p; executable_code_for_p; }; process type p { declarations_for_p; executable_code_for_p; };

28. 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;

29. 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

30. Operating Systems PrinciplesProcess Management and CoordinationLecture 2: Processes and Their Interaction Basic Process Interactions

31. 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

32. Resource Competition Shared source, e.g., common data

33. 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.

34. Example x = 0; cobegin p1: ... x = x + 1; ... // p2: ... x = x + 1; ... coend What value of x should be after both processes execute?

35. 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; . . .

36. 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; . . .

37. 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.

38. 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.

39. 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)

40. Software Solutions • Solve the problem without taking advantage of special machine instructions and other hardware.

41. 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

42. 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?

43. 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

44. 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?

45. 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

46. 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.

47. 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.

48. 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.

49. 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

50. 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    