1 / 9

Suzuki Kasami Example

Suzuki Kasami Example. Consider 5 Sites. 0. 0. 0. 0. 0. RN1. 0. 0. 0. 0. 0. RN2. 1. 2. 4. 5. 3. 1. 2. 4. 5. 3. S1. n=1. S2. n=2. 0. 0. 0. 0. 0. LN. 1. 2. 4. 5. 3. Token at Site S1. S3. n=3. Q. { } (empty). 0. 0. 0. 0. 0. RN3. S5. n=5. 1. 2. 4.

raja-everett
Télécharger la présentation

Suzuki Kasami Example

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. Suzuki Kasami Example

  2. Consider 5 Sites 0 0 0 0 0 RN1 0 0 0 0 0 RN2 1 2 4 5 3 1 2 4 5 3 S1 n=1 S2 n=2 0 0 0 0 0 LN 1 2 4 5 3 Token at Site S1 S3 n=3 Q { } (empty) 0 0 0 0 0 RN3 S5 n=5 1 2 4 5 3 n=4 0 0 0 0 0 S4 RN5 0 0 0 0 0 RN4 1 2 4 5 3 1 2 4 5 3

  3. Site S1 wants to enter CS • S1 won’t execute Request Part of the algorithm • S1 enters CS as it has token • When S1 release CS,it performs following tasks • LN[1] = RN1[1] = 0 i.e. same as before • If during S1’s CS execution, any request from other site (say S2) have come then that Site’s id will now be entered into the queue if RN1[2] = LN[2]+1 • So if site holding (not received from other) the token enters CS then overall state of the system won’t change it remains same.

  4. Site S2 wants to enter CS • S2 does not have token so it sends REQUEST(2,1) message to every other site • Sites S1,S3,S4 and S5 updates their RN as follows 0 1 0 0 0 1 2 4 5 3 It may be possible that S2’s request came at S1 when S1 is under CS execution So at this point S1 will not pass the token to S2. It will finish its CS and then adds S2 Into Queue because at that point RN1[2] = 1 which is LN[2]+1 Now as the queue is not empty, so S1 pass token to S2 by removing S2 entry from Token queue.

  5. Site S2 Sends REQUEST(2,1) 0 1 0 0 0 RN1 0 1 0 0 0 RN2 1 2 4 5 3 1 2 4 5 3 S1 REQUEST(2,1) n=1 S2 n=2 REQUEST(2,1) 0 0 0 0 0 LN 1 2 4 5 3 Token at Site S1 S3 Q {S2 } [Inserted only when S1 leave CS] 0 1 0 0 0 RN3 S5 REQUEST(2,1) n=5 1 2 4 5 3 REQUEST(2,1) n=4 0 1 0 0 0 S4 0 1 0 0 0 RN4 1 2 4 5 3 1 2 4 5 3

  6. 0 0 0 0 0 LN 1 2 4 5 3 Q{} Site S1 Sends Token to S2 0 1 0 0 0 RN1 0 1 0 0 0 RN2 1 2 4 5 3 1 2 4 5 3 S1 n=1 S2 n=2 LN Token at Site S2 S3 0 1 0 0 0 RN3 S5 n=5 1 2 4 5 3 n=4 0 1 0 0 0 S4 0 1 0 0 0 RN4 1 2 4 5 3 1 2 4 5 3

  7. 0 1 0 0 0 LN 1 2 4 5 3 Q{} Site S2 Leaves CS 0 1 0 0 0 RN1 0 1 0 0 0 RN2 1 2 4 5 3 1 2 4 5 3 S1 n=1 S2 n=2 LN Token at Site S2 S3 0 1 0 0 0 RN3 S5 n=5 1 2 4 5 3 n=4 0 1 0 0 0 S4 0 1 0 0 0 RN4 1 2 4 5 3 1 2 4 5 3

  8. Now suppose S2 again wants to enter CS • S2 can enter CS as token queue is empty i.e. no other site has requested for CS and token is currently held by S2 • When S2 release CS it updates LN[2] as RN2[2] which is same as 1.

  9. Salient Points • A site updates its RN table as soon as it receives Request message from any other site [At this point a site may hold an ideal token or may be executing CS] • When a site enters CS without sending request message (i.e. when site wants to again enter CS without making request) then its RN entry and LN entry of token remains unchanged • A site can be added in to token queue only by the site who is releasing the CS • A site holding the token can repeatedly enter CS until it does not send token to some other site. • A site gives priority to other sites with outstanding requests for the CS over its pending requests for the CS

More Related