1. CS603 Process Synchronization February 11, 2002

2. Synchronization: Basics Problem: Shared Resources –Generally data –But could be others Approaches: –Model as sequential process –Model as parallel process Models assume global state! P1 P3P2

3. Global State Plausible in sequential system –But expensive –Solution: Send only needed portions of state What about Parallel model? –Distributed Virtual Memory! –With all the advantages and problems –What about non-memory resources? Question: What is global state?

4. Alternative: Mutual Exclusion Control access to shared resources –Only one process allowed to use resource at a time –Doesn’t require global state Sequential simulation can be viewed as mutual exclusion on entire state –But we can do better –Control only when resource in contention

5. Mutual Exclusion Techniques: Centralized Approach Request for resource sent to coordinator When available, responds “go ahead” When done, requestor sends “release” to coordinator Problems: –Doesn’t scale –Single point of failure –No way to distinguish failure from resource in use

6. Evaluating Mutual Exclusion Techniques Does it guarantee mutual exclusion? Does it prevent starvation? –If a process requests a resource, it is guaranteed to eventually get it –Assumes resource use bounded Is it fair? –What do we mean by fair? Does it scale? Does it handle failures?

7. Mutual Exclusion: Token Passing Token associated with resource –Initially held by “first” process –When resource not in use, token passed to next process Problems: –Potential delay Resource need and path of token unrelated –Communication cost –Failure causing “loss of token”

8. Mutual Exclusion: Token Passing Does it guarantee mutual exclusion? –Yes Does it prevent starvation? –Yes Is it fair? –Everyone gets their turn –But not “first-come, first-served” Does it scale? –Yes Does it handle failures? –No

9. Timestamp-based request (Lamport ’78) When resource needed broadcast request: –Name of resource needed –Process ID of requestor –Time at requestor On receiving a request message: –If using resource, queue request –If waiting for resource, compare request timestamp with your own request timestamp Lowest “wins” – if other is lower, send “OK”, else queue –If not waiting for or using resource, send “OK” When OK received from all other processes, use resource

10. Timestamp-based request (Lamport ’78) Does it guarantee mutual exclusion? –Yes Does it prevent starvation? –Yes Is it fair? –First-come, first-served Where “first” defined by clock synchronization Does it scale? –Requires all processes to respond to any request Does it handle failures? –No single point of failure –Instead, n points of failure!

11. Comparison of Approaches AlgorithmMessages per request Delay (in messages) Fault tolerance Coordinator32Single point of failure Token Ring1 to ∞0 to n-1n points of failure Timestamp2 (n-1) n points of failure

12. What’s next? Fault tolerant solutions –Colored Ticket Algorithm Multiple resources –Dining philosophers problem