1 / 66

Chapter 8: Basic Synchronization Principles

Chapter 8: Basic Synchronization Principles. Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155. steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818.

race
Télécharger la présentation

Chapter 8: Basic Synchronization Principles

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 8: Basic Synchronization Principles Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818 † These slides have been modified from a set of originals by Dr. Gary Nutt.

  2. Purpose of this Chapter • What is Synchronization? • Is Synchronization Supported by PL? OS? HW? • Why do we Need to Synchronize? • Promote Sharing of Resources, Data, etc. • Handle Concurrent Behavior of Processes • What are Potential Problems without Synchronization? • Data Inconsistency • Deadlock • Non-Determinacy of Computations • What are Classic Synchronization Techniques? • Critical Sections • Semaphores

  3. What is Synchronization? • Ability of Two or More Serial Processes to Interact During Their Execution to Achieve Common Goal • Recognition that “Today’s” Applications Require Multiple Interacting Processes • Client/Server and Multi-Tiered Architectures • Inter-Process Communication via TCP/IP • Fundamental Concern: Address Concurrency • Control Access to Shared Information • Historically Supported in Database Systems • Currently Available in Many Programming Languages

  4. Suppose X and Y are Concurrently Executing in Same Address Space What are Possibilities? Thread Synchronization • What Does Behavior at Left Represent? • Synchronous Execution! • X Does First Part of Task • Y Next Part Depends on X • X Third Part Depends on Y • Threads Must Coordinate Execution of Their Effort X Y 1 2 3

  5. Will Second Part Still Finish After Third Part? Will Second Part Now Finish Before Third Part? What Happens if Variables are Shared? Thread Synchronization • Now, What Does Behavior at Left Represent? • Asynchronous Execution! • X Does First Part of Task • Y Does Second Part Concurrent with … • X Doing Third Part • What are Issues? X Y 1 2 3

  6. Recall Synchronization in MBDS B3 A1 K12 Request Preparation Post Processing C4 K12 D6 Put Msg. Get Msg. F15 From Other Backend E15 To Backend(s) Get Msg. Put Msg. K12 D6,F15 E15 Record Processing I16 Directory Management J23 H22 Concurrency Control G21 Disk I/O • Multiple Interacting Processes with 50 Message Types for 6 Database Transactions

  7. What are Synchronization Issues in MBDS? • Coordination of Synchronous Behavior … • within Controller and Backend to Allow Multiple Active Requests within • Each Process • Requests at Different Stages in Different Processes • Between Controller and Backends to Allow • A Request to be Processed by All Backends • A Request to be Processed by One Backend • Among Multiple Backends to Allow a Backend • to Synchronize its Work on one Request with Other Backends • to Forward Results to Another Backend

  8. Is Synchronization Supported by PL? OS? HW? • What is Level of Concurrency Supported in Each? • No Widely-Accepted Concurrent Programming Languages (see Next Slide!) • No Concurrent Programming Paradigm • Each Problem Requires Careful Consideration • There is No Common Model • Mathematical Models for Distributed Processing • See SOR Example on P 189 for One Model • Input/Output Automata (IOA) • OS Tools to Support Concurrency are, of Necessity, Low Level • HW Support via DMA and Other Architectures

  9. Concurrency in Programming Languages(Circa 1995) C-BasedC++Based Distributed OOL Others Concurr Cob ABC++ Amber A’UM cooC AKC++ Argus Beta PROCOL Charm++ Con Meld Blaze 2 Comp C++ DC++ CLIX Small-Talk Concert C++ DOWL Clueter86 ConSmalltalk Conc C++ DROL Ellie CST COOOL Dsmalltalk Fleng++ ESP Eden Hybrid Actor-Based HPC++ Emerald Java ABCL+ MPC++ Flame (C++) Lamina Acore Mentat Guile NEXUS ACT++ PARMACS Heraklit O-CPU Act1,2,3 PRESTO KITARA Orient 84 Actalk pC++ Must PO Actra UC++ Orca POOL-T/I ALBA WARASA SINA A-NETL ADA95 Solve Cantor, Janus Extended Eiffel Plasma-II, Rosette

  10. Why Do we Need to Synchronize? • Promote Sharing of Resources, Data, etc. • Cooperating Processes Norm Not Exception • Difficult to Program Solutions • Recall MBDS Again • Handle Concurrent Behavior of Processes • Multiple Processes Interacting via OS Resources • Under Control of Process Manager/Scheduler • Performance, Parallel Algorithms & Computations • Multi-Processor Architectures (CSE228) • Different OS to Handle Multiple Processors • Client/Server and Multi-Tier Architectures

  11. Software Engineering IssuesLanguages, Tools, and Technologies • Java has Emerged as Programming Language of Choice for Majority of Software Development • Distributed Internet-Based Applications • Legacy/COTS (NAIC/FIDO) Integration • Targeted for eCommerce (Future) • Focused on Choosing Methodologies, Tools, and Technologies • Integrated Toolset (e.g., MS Office) • Evaluating “Similar” Tools to Choose Best One (e.g., Mail Programs) • Assessing Status of Technology Today and for Future (i.e., 1 year, 2 years, 5 years) • Planning and System Maintenance for Tomorrow

  12. The CT Insurance Department Project • Purposes • Upgrade Computing Environment to 21st Century Technologies • Support all Existing Capabilities • Add New Functionality that Provide More Opportunities for Personnel to Perform Their Jobs in a Cost Effective Manner • Institute Philosophy that Promotes Future Improvements and Extension to eCommerce • Partnership of • CT Insurance Department Personnel • UConn’s Computer Science & Engrg. Dept. • GentronicsWang Corporation • Merrill Clark Corporation

  13. Software Architectural Structure Two-Tier, Three-Tier, Four-Tier From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html

  14. Santa Cruz Widgets (2-tier) Oracle

  15. Three-Tier Example Oracle AT NAIC

  16. Four-Tier Architecture Example

  17. The CT Insurance Department Project • Purposes • Upgrade Computing Environment to 21st Century Technologies • Support all Existing Capabilities • Add New Functionality that Provide More Opportunities for Personnel to Perform Their Jobs in a Cost Effective Manner • Institute Philosophy that Promotes Future Improvements and Extension to eCommerce • Partnership of • CT Insurance Department Personnel • UConn’s Computer Science & Engrg. Dept. • Gentronics Corporation • Merrill Clark Corporation

  18. Business Process Model: Scanning and Initial Data Entry DB DB DB DB DB Historical Records Completed Applications Licensing Supervisor Review Scanner Licensing Division Scanning Operator Stored Images Printer Licensing Division Data Entry Operator Basic Information Entered New Licenses New Appointments FOI Letters (Request Information, etc.)

  19. Software Architectural Structure A First Licensing Prototyping Database Server Running Oracle Initial Data Entry Operator (Scanning & Posting) Advanced Data Entry Operators Analyst Manager 10-100MB Network RMI Registry Document Server Stored Images/CD RMI Act. Obj/Server RMI Act. Obj/Server Functional Server

  20. Using RMI in Licensing Prototype Adv. Data Entry Analyst Manager rmid rmiregistry Server Activation Object ActivatableImplementation.java Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl rmiregistry 1100 rmiregistry 1101 rmiregistry 1102 Document Server Stored Images/CD Database Server Running Oracle

  21. Using RMI in Licensing Prototype Adv. Data Entry • Client Looks Up Activation Object • rmid Creates New Activation Object • rmid Binds Activation Object Interface to Client rmid rmiregistry • Client can Now Directly Communicate with Unicast Remote Object Implementation Class(LicenseImpl) • Client Can Invoke Methods and Receive Results • Client Requests a Unicast Remote Object Activation Object ActivatableImplementation.java • Activatable Object Returns to Client All Necessary Info Unicast Remote Object LicensingImpl • Activatable Object Creates New Unicast Remote Object and Binds to Unique Name on a Registry (Round Robin) rmiregistry 1100

  22. What are Potential Problems without Synchronization? • Data Inconsistency • Lost-Update Problem • Impact on Correctness of Executing Software • Deadlock • Two Processes • Each Hold Unique Resource and Want Resource of Other Process • Processes Wait Forever • Non-Determinacy of Computations • Behavior of Computation Different for Different Executions • Two Process Produce Different Results When Executed More than Once on Same Data

  23. What are Classic Synchronization Techniques? • Goal: Shared Variables and Resources • Two Approaches: • Critical Sections • Define a Segment of Code as Critical Section • Once Execution Enters Code Segment it Cannot be Interrupted by Scheduler • Release Point for Critical Section for Interrupts • Semaphores • Proposed in 1960s by E. Dijkstra • Utilizes ADTs to Design and Implement Behavior that Guarantees Consistency and Non-Deadlock

  24. Critical Sections • Two Processes Share “balance” Data Item • Remember, Assignment is Not Atomic, but May Correspond to Multiple Assembly Instructions • What is Potential Problem re. Chapter 7? shared float balance; Code for p1Code for p2 . . . . . . balance = balance + amount; balance = balance - amount; . . . . . . p1 p2 balance

  25. Critical Sections Code for p1Code for p2 load R1, balanceload R1, balance load R2, amount load R2, amount add R1, R2 sub R1, R2 store R1, balancestore R1, balance • Recall the Code Below • What Happens if Time Slice Expires at Arrow and an Interrupt is Generated? shared double balance; Code for p1Code for p2 . . . . . . balance = balance + amount; balance = balance - amount; . . . . . .

  26. Critical Sections (continued) Code for p1Code for p2 load R1, balanceload R1, balance load R2, amount load R2, amount add R1, R2 sub R1, R2 store R1, balancestore R1, balance • There is a Race to Execute Critical Sections • Sections May Be Different Code in Different Processes: Cannot Detect With Static Analysis • Results of Multiple Execution Are Not Determinate • Need an OS Mechanism to Resolve Races • If p1Wins, R1 and R2 Added to Balance - Okay • If p2Wins, its Changed Balance Different from One Held by p1 which Adds/Writes Wrong Value

  27. One Solution: Disabling Interrupts • In Code Below, Disable Interrupts • What are Potential Problems? • Interrupts Could Be Disabled Arbitrarily Long • Were Trusting Software Engineers • Unintentional(Infinite Loop) or Malicious Code • Concurrent PLs Enforce Primitives at Compile • Really Only Want to Prevent P1 and P2 From Interfering With One Another • Another Solution: Using Shared “Lock” Variable shared double balance; Code for p1Code for p2 disableInterrupts(); disableInterrupts(); balance = balance + amount; balance = balance - amount; enableInterrupts(); enableInterrupts();

  28. Using a Lock Variable What if Interrupt Occurs Here? What if Interrupt Occurs Here? • Shared lock Flag Initialized to False • First Process to be Active Sets lock to TRUE • Enter Critical Section • Change balance • Set lock to FALSE • Leave Critical Section • Where are Two Trouble Spots? shared boolean lock = FALSE; shared double balance; Code for p1 /* Acquire the lock */ while(lock) ; lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE; Code for p2 /* Acquire the lock */ while(lock) ; lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE;

  29. Using a Lock Variable shared boolean lock = FALSE; shared double balance; Code for p1 /* Acquire the lock */ while(lock) ; lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE; Code for p2 /* Acquire the lock */ while(lock) ; lock = TRUE; /* Execute critical sect */ balance = balance + amount; /* Release lock */ lock = FALSE; Blocked at while p2 p1 lock = TRUE lock = FALSE Interrupt Interrupt Interrupt

  30. Lock Manipulation What Occurs Here? • Consider the Following enter/exit Primitives that Will be Utilized to Insure No Interrupts During • How Does Code Below Insure that Interrupts are Disabled? enter(lock) { exit(lock) { disableInterrupts(); disableInterrupts(); /* Loop until lock is TRUE */ lock = FALSE; while(lock) { enableInterrupts(); /* Let interrupts occur */ } enableInterrupts(); disableInterrupts(); } lock = TRUE; enableInterrupts(); } Remember, Need Location for Interrupts to Occur During Attempt to Acquire Lock!

  31. Utilizing Enter and Exit • Example: List Manipulator • Add or Delete an Element From a List • Adjust the List Descriptor, e.g., Length • Modify List Content and Length • A Transaction is a List of Operations • The System Begins to Execute a Transaction • Execution Must Occur on All Operations that Comprise Transaction Without Interruption • Or, the Transaction Must Not Execute Any Operations at All • Concept of Atomic Transaction

  32. Processing Two Transactions shared boolean lock2 = FALSE;lock1 = FALSE; shared list L; Code for p1Code for p2 . . . . . . /* Enter CS to delete elt */ /* Enter CS to update len */ enter(lock1); enter(lock2); <delete element>; <update length>; /* Exit CS */ /* Exit CS */ exit(lock1); exit(lock2); <intermediate computation>; <intermediate computation> /* Enter CS to update len */ /* Enter CS to add elt */ enter(lock2); enter(lock1); <update length>; <add element>; /* Exit CS */ /* Exit CS */ exit(lock2); exit(lock1); . . . . . . • Notice Any Problems with Code for Processes? • Interrupt of p1 After Delete But Before Update • If p2Adds Element and Updates Length, Inconsistency Occurs

  33. Deadlock shared boolean lock1 = FALSE; lock2 = FALSE;shared list L; Code for p1Code for p2 . . . . . . /* Enter CS to delete elt */ /* Enter CS to upd len */ enter(lock1); enter(lock2); <delete element>; <update length>; <intermediate computation>; <intermediate comp> /* Enter CS to update len */ /* Enter CS to add elt */ enter(lock2); enter(lock1); <update length>; <add element>; /* Exit both CS */ /* Exit both CS */ exit(lock1); exit(lock2); exit(lock2); exit(lock1); . . . . . . • Why and How Does Deadlock Occur?

  34. Coordinating Processes • Can Synchronize With FORK, JOIN & QUIT • Terminate Processes With QUIT to Synchronize • Create Processes Whenever Critical Section is Complete • See Figure 8.7 • Problems with All Approaches so Far • Reliance on Software Engineers • Error Prone and Difficult to Enforce • Alternative is to Create OS Primitives Similar to the enter/exit Primitives

  35. Some Constraints for“Ideal” Synchronization Mechanism • Processes will Enter Critical Sections • Mutual Exclusion: Only One Process at any One Time in Allowed in the CS • Only Processes Competing for a CS are Involved in Resolving Who Enters the CS • Once a Process Attempts to Enter its CS, it Cannot be Postponed Indefinitely • After Requesting Entry, Only a Bounded Number of Other Processes May Enter Before the Requesting Process • Latter Two Points Prevent Starvation!

  36. Assumptions About Solutions • Memory Read/Writes Are Indivisible • Process A Reads X; Process B Writes X • Either • A Reads X; B Writes X • B Writes X; A Reads X • Simultaneous Attempts Result in Some Arbitrary Order of Access • There is No Priority Among the Processes • Relative Speeds of the Processes/Processors is Unknown • Processes Are Cyclic and Sequential

  37. Dijkstra Semaphore • Classic Paper Describes Several Software Attempts to Solve the Problem (See Exercise 4, Section 8.6) • Dijkstra First Found a Software Solution • Then Proposed Simpler Hardware-Based Solution • What is a Semaphore S? • A Nonnegative Integer Variable • Can Only Be Changed or Tested by Two Indivisible Functions: • For V(s), No Interrupt is Possible • For P(s), Interrupt During {wait}; Only V(s): [s = s + 1] P(s): [while(s == 0){wait}; s = s - 1]

  38. How Do P & V Work? • What is the Initial Value of Binary Semaphore? • Initial Value Set as Part of Shared Variable • semaphore mutex = 1; • Followed by Spawning of Two or More Processes • What Does it Mean When mutex = 0? • Process X Executed P(mutex) with mutex = 1 • What About Other Processes Trying P(mutex)? • Others Wait Until Process X Does V(mutex) • If X is Interrupt Before V, Others Still Wait V(mutex): [mutex = mutex + 1] P(mutex): [while(mutex == 0){wait}; mutex = mutex - 1]

  39. Using Semaphores to Solve the Canonical Problem proc_0() { proc_1() { while(TRUE) { while(TRUE { <compute section>; <compute section>; P(mutex);P(mutex); <critical section>; <critical section>; V(mutex);V(mutex); } } } } semaphore mutex = 1; // Shared variable fork(proc_0, 0); fork(proc_1, 0); • What if First P(mutex); Called by proc_0? • s = 1 while false so s = 0 • What if Interrupt Occurs in CS of proc_0? • proc_1() Waits Until proc_0 Resumes • When CS Finishes V is Fired to Set s = 1 V(s):[s = s + 1] P(s):[while(s==0) {wait}; s = s - 1]

  40. Shared Account Problem proc_0() { proc_1() { . . . . . . /* Enter the CS */ /* Enter the CS */ P(mutex); P(mutex); balance += amount; balance -= amount; V(mutex); V(mutex); . . . . . . } } semaphore mutex = 1; // Shared variable fork(proc_0, 0); fork(proc_1, 0); • Assume Following Values: • balance = 200 • amount = 50 amount = 75 • What are Possible Results? • Is there a Lost Update? V(s):[s = s + 1] P(s):[while(s==0) {wait}; s = s - 1]

  41. proc_0 Executes P First If proc_0 Interrupted Waits proc_1 Eventually proc_0 Resumes balance = 250 proc_0 Executes V proc_1 Executes P Sets balance = 175 proc_1 Executes V proc_1 Executes P First If proc_1 Interrupted proc_0 Waits Eventually proc_1 Resumes balance = 125 proc_1 Executes V proc_0 Executes P Sets balance = 175 proc_0 Executes V • balance = 200 • amount = 50 • amount = 75 V(s):[s = s + 1] P(s):[while(s==0) {wait};s=s-1] proc_0() { proc_1() { . . . . . . /* Enter the CS */ /* Enter the CS */ P(mutex); P(mutex); balance += amount; balance -= amount; V(mutex); V(mutex); . . . . . . } }

  42. Two Shared Variables proc_A() { while(TRUE) { <compute section A1>; update(x); /* Signal proc_B */ V(s1); <compute section A2>; /* Wait for proc_B */ P(s2); retrieve(y); } } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0); fork(proc_B, 0); • What is Execution Process That Guarantees • x and y are Read After They’re Written? proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); <compute section B1>; update(y); /* Signal proc_A */ V(s2); <compute section B2>; } }

  43. Execution ProcessTwo Shared Variables integer x,y; semaphore s1=0; semaphore s2=0; • Doesn’t Matter if Interrupt Occurs Anywhere • Read of Written Data Only After Semaphore Secured proc_A() { while(TRUE) { <compute section A1>; update(x); /* Signal proc_B */ V(s1); <compute section A2>; /* Wait for proc_B */ P(s2); retrieve(y); } } P(s1) will not Execute Until V(s1) sets s1 to 1 x Written Before Read proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); <compute section B1>; update(y); /* Signal proc_A */ V(s2); <compute section B2>; } } P(s2) will not Execute Until V(s2) sets s2 to 1 y Written Before Read

  44. The Driver-Controller Interface • The Semaphore Principle is Logically Used With the busy and done Flags in a Controller • Driver Signals Controller With a V(busy), Then Waits for Completion With P(done) • Controller Waits for Work With P(busy), Then Announces Completion With V(done) • Semaphores Guarantee that Handshaking Always Correct Between Driver and Controller • See in the Cockpit, Page 204

  45. Bounded Buffer Empty Pool Producer Consumer Full Pool • Producer/Consumer Model • Processes Communicate by • Producer Obtains Empty Buffer fr. Pool • Producer Fills Buffer & Places in Full Pool • Consumer Obtains Info. By Picking Buffer fr. Full Pool • Consumer Copies Info Out of Buffer • Consumer Places Buffer in Empty Pool • N Fixed Number of Buffers • Utilize Counting/Binary Semaphores

  46. Bounded Buffer consumer() { buf_type *next, *here; while(TRUE) { /* Claim full buffer */ P(full); P(mutex); here = obtain(full); V(mutex); copy_buffer(here, next); P(mutex); release(here, emptyPool); V(mutex); /* Signal an empty buffer */ V(empty); consume_item(next); } } producer() { buf_type *next, *here; while(TRUE) { produce_item(next); /* Claim an empty */ P(empty); P(mutex); here = obtain(empty); V(mutex); copy_buffer(next, here); P(mutex); release(here, fullPool); V(mutex); /* Signal a full buffer */ V(full); } } semaphore mutex = 1; /* A binary semaphore */ semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[N]; fork(producer, 0); fork(consumer, 0);

  47. semaphore mutex = 1; semaphore full = 0; semaphore empty = N; buf_type buffer[N]; Execution ProcessBounded Buffer Producers Want Empty Buffers Consumers Want Full Buffers Distinct Empty Buffer Goes to Only 1 Producer Protect Changes to Full Pool Only One Process Accesses Full Pool Protect Changes to Empty Pool Full Buffer Now Available Empty Buffer Now Available producer() { buf_type *next, *here; while(TRUE) { produce_item(next); /* Claim an empty */ P(empty); P(mutex); here = obtain(empty); V(mutex); copy_buffer(next, here); P(mutex); release(here, fullPool); V(mutex); /* Signal a full buffer */ V(full); } } consumer() { buf_type *next, *here; while(TRUE) { /* Claim full buffer */ P(full); P(mutex); here = obtain(full); V(mutex); copy_buffer(here, next); P(mutex); release(here, emptyPool); V(mutex); /* Signal an empty buffer */ V(empty); consume_item(next); } }

  48. The Readers-Writers Problem • Establish Protocol Regarding R/W Access to Shared Resource • Writer Excludes Readers (1 W, No R or n R) • Write Allows Readers (1W and n R) • What is Difference re. Consistency? • What is Readers-Writers Problem? • Shared Resource (e.g., a File) • Readers Share with Other Readers • Writer has Exclusive Access • What are Potential Problems? • When does Write Occur? • Can Readers Starve out Writer?

  49. Readers-Writers Problem Writer Reader Writer Reader Writer Reader Writer Reader Writer Reader Writer Reader Writer Reader Reader Shared Resource

  50. Readers-Writers Problem Writer Writer Writer Writer Writer Writer Writer Reader Reader Reader Reader Reader Reader Reader Reader Shared Resource

More Related