Process Structure and Synchronization in Computer Science: A Spring 2009 Course Overview -, Study notes of Computer Science

Download Process Structure and Synchronization in Computer Science: A Spring 2009 Course Overview - and more Study notes Computer Science in PDF only on Docsity! 2 Processes and Interactions. 2.1 The Process Notion 2 2 Defining and Instantiating Processes. – Precedence Relations – Implicit Process Creation Dynamic Creation With fork And join– – Explicit Process Declarations 2.3 Basic Process Interactions Competition: The Critical Section Problem– – Cooperation 2.4 Semaphores – Semaphore Operations and Data – Mutual Exclusion – Producer/Consumer Situations 2 5 Event Synchronization. CompSci 143A 1Spring, 2009 Processes • A process is the activity of executing a program CPU Al ll d t kon a . so, ca e a as . • Conceptually… – Each process has its own CPU – Processes are running concurrently • Physical concurrency = parallelism Thi i lti l CPUs requ res mu p e s • Logical concurrency = time-shared CPU • Processes cooperate (shared memory messages , , synchronization) • Processes compete for resources CompSci 143A 2Spring, 2009 Specifying precedence relations • Process-flow graphs (unrestricted) • Properly nested expressions/graphs (also known as series-parallel graphs) CompSci 143A 5Spring, 2009 Process flow graphs • Directed graphs • Edges represent processes i i i i i i i f• Vert ces represent n t at on, term nat on o processes CompSci 143A 6Spring, 2009 Examples of Precedence Relationships (Process Flow Graphs) CompSci 143A 7 Figure 2-1 Spring, 2009 Properly nested expressions • Two primitives which can be nested: , – Serial execution • Expressed as S(p1 p2 ) , , … • Execute p1, then p2, then … – Parallel execution • Expressed as P(p1, p2, …) • Concurrently execute p1, p2, • A graph is properly nested if it corresponds to a properly nested expression CompSci 143A 10Spring, 2009 Examples of Precedence Relationships (Process Flow Graphs) CompSci 143A 11 Figure 2-1 Spring, 2009 Properly nested process flow graphs • (c) corresponds to the properly nested expression – S(p1, P(p2, S(p3, P(p4, p5)), p6), P(p7, p8)) • (d) is not properly nested – (proof: text, page 44) CompSci 143A 12Spring, 2009 Cobegin/coend statement • syntax: cobegin C1 // C2 // … // Cn coend • meaning: – All Ci may proceed concurrently – When all of the Ci’s terminate, the statement following the cobegin/coend can proceed • cobegin/coend statements have the same expressive power as S/P notation – S(a,b) ≡ a; b (sequential execution by default) – P(a,b) ≡ cobegin a // b coend CompSci 143A 15Spring, 2009 cobegin/coend example Figure 2-4 cobegin Time Date // Mail //_ { Edit; cobegin { Compile; Load; Execute} // { Edit; cobegin Print // Web coend} coend } coend CompSci 143A 16Spring, 2009 Data parallelism • Same code is applied to different data • The forall statement t f ll ( t ) t t t– syn ax: ora parame ers s a emen s – Meaning: P if f d i• arameters spec y set o ata tems • Statements are executed for each item concurrently CompSci 143A 17Spring, 2009 Explicit program creation: fork/join • cobegin/coend are limited to properly nested graphs • forall is limited to data parallelism • fork/join can express arbitrary functional parallelism (any process flow graph) CompSci 143A 20Spring, 2009 The fork and join primitives • Syntax: fork x Meaning: create new process that begins executing at label x • Syntax: join t,y Meaning: t = t–1; if (t==0) goto y; The operation must be indivisible. (Why?) CompSci 143A 21Spring, 2009 fork / join example • Example: Graph in Figure 2-1(d) 1 2 2 3t = ; t = ; 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 6 j i t2 L8 it: p ; o n , ; qu ; L8: p8; quit; CompSci 143A 22Spring, 2009 Explicit Process Declarations process p process p1 declarations_for_p1 begin ... end process type p2 declarations_for_p2 b i deg n ... en begin ... q = new p2; ... end CompSci 143A 25Spring, 2009 Thread creation in Java • Define a runnable class Class MyRunnable implements runnable { … run() {…} } • Instantiate the runnable, instantiate and start a thread that runs the runnable Runnable r = new MyRunnable(); Thread t = new Thread(r); t.start; CompSci 143A 26Spring, 2009 Process Interactions • Competition/Mutual Exclusion – Example: Two processes both want to access the same resource . • Cooperation E l– xamp e: Producer → Buffer → Consumer CompSci 143A 27Spring, 2009 The Critical Section Problem • Problem statement: b ico eg n p1: while(1) {CS1; program1;} // 2 hil (1) {CS2 2 }p : w e ; program ; // ... // pn: while(1) {CSn; programn;} coend • Guarantee mutual exclusion: At any time, at most one process should be executing within its C icritical section ( s ). CompSci 143A 30Spring, 2009 The Critical Section Problem In addition to mutual exclusion, prevent mutual blocking: 1. Process outside of its CS must not prevent other processes f t i it CSrom en er ng s . (No “dog in manger”) 2. Process must not be able to repeatedly reenter its CS and starve other processes (fairness) 3. Processes must not block each other forever (no deadlock) 4. Processes must not repeatedly yield to each other (“after you”--“after you”) (no livelock) CompSci 143A 31Spring, 2009 The Critical Section Problem • Solving the problem is subtle • We will examine a few incorrect solutions before describing a correct one: Peterson’s algorithm CompSci 143A 32Spring, 2009 Algorithm 3 • Like #2, but reset intent variables (c1 and c2) each time: int c1 = 0, c2 = 0; cobegin p1: while (1) { c1 = 1; if (c2) c1 = 0; //go back, try again else {CS1; c1 = 0; program1} } // p2: while (1) { c2 = 1; if ( 1) 2 0 // b k t i c c = ; go ac , ry aga n else {CS2; c2 = 0; program2} } coend • Violates blocking requirements (2) and (4), fairness and livelock CompSci 143A 35Spring, 2009 Peterson’s algorithm • Processes indicate intent to enter CS as in #2 and #3 (using c1 and c2 variables) • After a process indicates its intent to enter, it (politely) tells the other process that it will wait (using the willWait variable) • It then waits until one of the following two conditions is true: Th th i t t i t t– e o er process s no ry ng o en er; or – The other process has said that it will wait (by changing the value of the willWait variable.) CompSci 143A 36Spring, 2009 Peterson’s Algorithm 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 • Guarantees mutual exclusion and no blocking CompSci 143A 37Spring, 2009 Notes on semaphores • Invented by Dijkstra • As we will see in Chapter 4, the waiting in the V operation can be implemented by – Blocking the process or , – Busy-waiting • Etymology: P( ) ft itt W it( ) thi k “P ”– s , o en wr en a s ; n ause : “P” from “passaren” (“pass” in Dutch) or from “prolagan,” combining “proberen” (“try”) and “verlagen” (“decrease”). – V(s) often written Signal(s);, think of the “V for Victory” 2-finger salute: “V” from “vrigeven” (“release”) or “verhogen” (“increase”). CompSci 143A 40Spring, 2009 Mutual Exclusion w/ Semaphores semaphore mutex = 1; b ico eg n 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; CompSci 143A 41Spring, 2009 Cooperation • Cooperating processes must also synchronize • Example: P1 waits for a signal from P2 before P1 proceeds. • Classic generic scenario: Producer → Buffer → Consumer CompSci 143A 42Spring, 2009 Events • An event designates a change in the system state that is of interest to a process Usually triggers some action– – Usually considered to take no time Principally generated through interrupts and– traps (end of an I/O operation, expiration of a timer, machine error, invalid address…) – Also can be used for process interaction – Can be synchronous or asynchronous CompSci 143A 45Spring, 2009 Synchronous Events • Process explicitly waits for occurrence of a specific event or set of events generated by another process • Constructs: – Ways to define events – E.post (generate an event) E it ( i il i d)– .wa wa t unt event s poste • Can be implemented with semaphores • Can be “memoryless” (posted event disappears if no process is waiting). CompSci 143A 46Spring, 2009 Asynchronous Events • Must also be defined posted , • Process does not explicitly wait id h dl• Process prov es event an ers • Handlers are evoked whenever event is posted CompSci 143A 47Spring, 2009