Token-Based Algorithms

A unique token is shared among all sites A site is allowed to enter a critical section (CS) if it possesses the token Token-based algorithms use sequence numbers instead of timestamps
A site increments its sequence number counter every time it makes a request for the token Use sequence number to distinguish between old and current requests

A correctness proof of token-based algorithms to ensure that DME is enforced is trivial because a site must hold the unique token before it can enter CS The issues of freedom from starvation and deadlock are prominent

Suzuki-Kasamis Broadcast Algorithm Raymonds Tree Algorithm

Suzuki-Kasamis Broadcast Algorithm Overview

To enter CS, a site broadcasts its REQUEST message to all other sites Upon receiving a REQUEST message, a site that has the token sends the token to the requesting site only if this site is not in CS.

If it is in CS, it sends the token only after it has exited the CS

A site can repeatedly enter CS as long as it holds the token and there are no pending requests from other sites

Major Design Issues

No RELEASE/REPLY messages as in assertionbased protocols Each site needs to be able to distinguish outdated REQUEST messages from current REQUEST messages (outstanding requests) The site with the token needs to know which site to send the token next

Important Data Structures

The token consists of
Q, a queue of requesting sites Array of integers, LN[1..N], where
LN[j] is the sequence number of the request that site Sj executed most recently N is the number of sites LN keeps track of the latest request that each site has executed

A site Si keeps an array of integers RNi[1..N] where RNi[j] is the largest sequence number received so far from Sj

A REQUEST(j,n) indicates that site Sj is requesting for CS with n as its sequence number

Example
RN1 0 0 0 S1 RN3 0 S3 RN2 0 Token 0 Queue 0 0 Token is idle at S1. S2 0 0 0 0

LN

Requesting CS

Site Si increments its sequence number, RNi[i] and sends a REQUEST(i,sn) to all other sites with sequence number sn When site Sj receives this message, it sets RNj[i]:=max(RNj[i],sn) If Sj has an idle token, it sends the token to Si if RNj[i]=LN[i]+1

Recall that the token LN[i] is the sequence number of the request that site Si executed most recently

Executing CS
Site Si executes CS when it has received the token

What happens if
S3 wants to enter its CS and the token is idle at S1 Then, S2 wants to enter its CS followed by S1

Example

after a request message got to S1 and S3 got the token and a request message reached S2
RN1 0 0 S1 1 RN3 0 S3 RN2 0 Token 0 Queue 0 0 Request message from S3 reaches S1 and S2 S2 0 1 0 1

LN

Releasing CS: Site Si will

Set LN[i] element of the token array to RNi[i] for every site Sj whose id is not in the token queue, append the id of Si to the token queue if RNi[j]=LN[j]+1 if token queue is nonempty after the above update, it deletes the top site id from the queue and sends the token to the site indicated by the id Note: Site Si gives priority to other sites with pending requests by executing the above algorithm

S3 enters CS and S2 wants to enter CS

RN1 0 0 S1 1 RN3 0 S3 RN2 0 S2 Token S2 Queue 0 0 1 0
Requests to enter CS from S2 (S2, 1) arrives at S3, but not at S1 S3 sends token to S2

0 1 1

0 1

LN

S3 exits its CS

Example (Contd)
1 1 RN1 0 0 S1 1 1 RN3 0 S3 1 RN2 0 1 S2 Token S1 Queue 0 0 1 1 LN S2s request just now arrives at S1 S1s request arrives at S2 and S3 S2 exits its CS Once S1 is done, the token is idle at S1 1 1 1

Question
Is the token queue necessary? Can we use only RNi or LNi and still ensure mutual exclusion? Previous example seems to show that we dont need the token queue, we just compare RNi[j] with token field LNi[j] to know which site needs to enter CS next Yes, we can ensure mutual exclusion, but starvation can occur

Token queue is used to collect the knowledge about outstanding requests from other sites
Some site that has the token may not be aware of requests from other sites due to message delays from the requesting site to this site

Token queue helps to ensure that a requesting site can enter CS in a finite time

Proof
A requesting site enters CS in finite time
Proof:
Token request reaches other sites in finite time and this request will be placed in the token queue in finite time Since there can be at most N-1 requests in front of this request, the requesting site can be in CS in finite time

Performance
The algorithm is simple and efficient: requires 0 or N messages per CS invocations Synchronization delay: 0 or T
No message is needed or the synchronization delay is zero if a site holds the idle token at the time of its request