1 / 12

CS 603 Process Synchronization: The Colored Ticket Algorithm

CS 603 Process Synchronization: The Colored Ticket Algorithm. February 13, 2002. Resource Sharing Problem. k identical resources, only one process can use a resource at a time Also referred to as “critical section” Each process has critical section

jontae
Download Presentation

CS 603 Process Synchronization: The Colored Ticket Algorithm

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. CS 603Process Synchronization:The Colored Ticket Algorithm February 13, 2002

  2. Resource Sharing Problem • k identical resources, only one process can use a resource at a time • Also referred to as “critical section” • Each process has critical section • Exclusion Property: At most k processes can be in their critical section at the same time • Impossibility of Deadlock: Processes eventually succeed in entering and leaving critical section • Full use: All k can be used simultaneously: • If fewer than k processes in their critical section, another should be able to enter its critical section before others exit theirs

  3. Naïve Solutions • Global Semaphore • Keeps count • Doesn’t prevent starvation • No notion of fairness • Reduce to single resource problem • Grocery store solution: choose your line • Doesn’t satisfy full use • Failure can cause starvation

  4. Fault tolerance • Fail-stop model: Process takes no more steps, unannounced • Can’t use timeout to tell failed from slow • If failed process causes any live process to deadlock/starve/etc., system is deemed to have failed • Failure while in critical section can tie up one resource • Must be careful with definition of “fair” • E.g. Distinction between “enter critical section” and “enabled to enter critical section”

  5. Colored Ticket Algorithm • Assumption: N processors, fixed k resources • Meets exclusion, deadlock, starvation, fairness properties • Simulates a queue (FIFO) • Robust: • Failure between requesting resource and releasing resource ties up one resource • Other failures have no effect • Uses O(N2) shared memory • Distributed virtual memory solutions can implement this • Optimal in space requirements • Lower bound Ω(N2) for robust algorithm to simulate queue

  6. Meets all properties Guarantees exclusion Fair (FIFO) No starvation Robust Problem: Distributed implementation of Queue True “shared memory” gives single point of failure Distributed implementation requires substantial space repeat forever start; ENQUEUE(i) wait until i is in one of the first k positions of QUEUE; finish; { Critical Section } start; REMOVE(i); finish; { Remainder Section } end repeat. Queue Algorithm

  7. Idea: Take ticket when you want a resource Ticket shows your place in line If resources available, ticket is valid When done with resource, validate next ticket Numbered ticket: Two shared variables TAKE: ISSUE++ VALIDATE: VALID++ IS-VALID: VALID≥ ticket Requires infinite space! local variable TICKET; repeat forever start; TICKET := TAKE-NEXT-TICKET; wait until IS-VALID(TICKET); finish; { Critical Section } start; VALIDATE-NEXT-TICKET(TICKET); finish; { Remainder Section }; end repeat. Ticket Algorithms

  8. Colored Ticket • Key: Not more than N outstanding tickets • Arithmetic mod N gives bounded space • Really only need M ≥ 1+max(k, N-k) Separate into “all in use” and “not all in use” • Can determine if all resources in use with three variables • B = (VALID/M = ISSUE/M) • V = VALID mod M • I = ISSUE mod M • If B then unused if V≥I else unused if V<I

  9. Divide tickets into blocks B true iff VALID and ISSUE in same block V (I) gives position of VALID (ISSUE) in block Replace numbered ticket by colored tickets T = (t, c); 0 ≤ t ≤ M-1; c is block B := VALID.c = ISSUE.c V := VALID.t I := ISSUE.t function LEADS(A,B): Boolean { if A.COLOR = B.COLOR return (A.VALUE ≥ B.VALUE) else return (A.VALUE < B.VALUE) } function IS-VALID(T): Boolean { if T.COLOR = VALID.COLOR return (T.VALUE ≤ VALID.VALUE) else if T.COLOR = ISSUE.COLOR return LEADS(VALID, ISSUE) else return true; } Colored Ticket:Simulate Numbered Ticket

  10. Colored Ticket:Bounding colors • Problem: Unbounded number of colors • Solution: At most k+1 colors in use • At most k tickets valid • At most (N-k) waiting • But these are consecutive! • Thus all will fit in one block

  11. constant M = 1 + max(k, N - k) global variable ISSUE = (0, 0),VALID = (k, 0); Global variable QUANT[k+1] = 0; function TAKE-NEXT-TICKET: ticket { if (ISSUE.VALUE < M – 1) ISSUE.VALUE++ else { ISSUE.VALUE = 0; if LEADS(ISSUE, VALID) then ISSUE.COLOR = NEW-COLOR Else ISSUE.COLOR = VALID.COLOR, } return ISSUE; } procedure VALIDATE-NEXT-TICKET(T) { if (VALID.VALUE < M – 1) VALID.VALUE++ else { VALID.VALUE = 0; if LEADS(VALID, ISSUE) VALID.COLOR = NEW-COLOR; Else VALID.COLOR = ISSUE.COLOR; } QUANT(VALID.COLOR)++; QUANT(T.COLOR)--; } function NEW-COLOR: integer { local variable C = 0; while QUANT[C] > 0 do C++; return C } Colored Ticket Algorithm

  12. Colored Ticket Algorithm:Space Requirements • ISSUE, VALID: Range 0..M • M bounded by N • QUANT: k variables range 0..M • Copies maintained at every site • Guarantees robustness • Various Distributed Shared Memory protocols guarantee consistency • Gives total space of O(N2) • Remember that k is constant • Paper gives lower bound proof

More Related