CS603 Process Synchronization February 11, 2002

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

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?

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

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

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?

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”

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

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

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!

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

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