Mutual Exclusion Continued

Quorum Based Algorithms Each process j requests permission from its quorum Qj Requirement: j, k :: Qj  Qk   j, k :: Qj Qk Rj = set of processes that request permission from Qj Rj need not be the same as Qj It is desirable that the size of Rj is same/similar for all processes

Maekawa’s algorithm Maekawa showed that minimum quorum size is N example quorums: for 3 processes: R0={P0,P1}, R1={P1,P2}, R2={P0,P2} for 7 processes: R0={P0,P1 ,P2}, R3={P0,P3 ,P4}, R5={P0,P5 ,P6}, R1={P1,P3 ,P5}, R4={P1,P4 ,P6}, R6={P2,P3 ,P6}, R2={P2,P4 ,P5}

Basic operation Requesting CS Entering CS Releasing CS process requests CS by sending request message to processes in its quorum a process has just one permission to give, if a process receives a request it sends back reply unless it granted permission to other process; in which case the request is queued Entering CS process may enter CS when it receives replys from all processes in its quorum Releasing CS after exiting CS process sends release to every process in its quorum when a process gets release it sends reply to another request in its queue

Possible Deadlock Since processes do not communicate with all other processes in the system, CS requests may be granted out of timestamp order example: suppose there are processes Pi, Pj, and Pk such that: Pj Ri and Pj Rk but Pk Ri and Pi Rk Pi and Pk request CS such that tsk < tsi if request Pi from reaches Pj first, then Pj sends reply to Pi and Pk has to wait for Pi out of timestamp order a wait-for cycle (hence a deadlock) may be formed

Maekawa’s algorithm, deadlock avoidance To avoid deadlock process recalls permission if it is granted out of timestamp order if Pj receives a request from Pi with higher timestamp than the request granted permission, Pj sends failed to Pi If Pj receives a request from Pi with lower timestamp than the request granted permission (deadlock possibility), Pj sends inquire to Pi when Pi receives inquire it replies with yield if it did not succeed getting permissions from other processes got failed

Token-based algorithms LeLann’s token ring Suzuki-Kasami’s broadcast Raymond’s tree

Token-ring algorithm (Le Lann) Processes are arranged in a logical ring At start, process 0 is given a token Token circulates around the ring in a fixed direction via point-to-point messages When a process acquires the token, it has the right to enter the critical section After exiting CS, it passes the token on Evaluation: N–1 messages required to enter CS Not difficult to add new processes to ring With unidirectional ring, mutual exclusion is fair, and no process starves Difficult to detect when token is lost Doesn’t guarantee “happened-before” order of entry into critical section

Suzuki-Kasami’s broadcast algorithm Overview: If a process wants to enter the critical section, and it does not have the token, it broadcasts a request message to all other processes in the system The process that has the token will then send it to the requesting process However, if it is in CS, it gets to finish before sending the token A process holding the token can continuously enter the critical section until the token is requested Request vector at process i : RNi [k] contains the largest sequence number received from process k in a request message Token consists of vector and a queue: LN[k] contains the sequence number of the latest executed request from process k Q is the queue of requesting process

Suzuki-Kasami’s broadcast algorithm Requesting the critical section (CS): When a process i wants to enter the CS, if it does not have the token, it: Increments its sequence number RNi [i] Sends a request message containing new sequence number to all processes in the system When a process k receives the request(i,sn) message, it: Sets RNk [i] to MAX(RNk [i], sn) If sn < RNk [i], the message is outdated If process k has the token and is not in CS (i.e., is not using token), and if RNk [i] == LN[i]+1 (indicating an outstanding request) it sends the token to process i Executing the CS: A process enters the CS when it acquires the token

Suzuki-Kasami’s broadcast algorithm Releasing the CS: When a process i leaves the CS, it: Sets LN[i] of the token equal to RNi [i] Indicates that its request RNi [i] has been executed For every process k whose ID is not in the token queue Q, it appends its ID to Q if RNi [k] == LN[k]+1 Indicates that process k has an outstanding request If the token queue Q is nonempty after this update, it deletes the process ID at the head of Q and sends the token to that process Gives priority to others’ requests Otherwise, it keeps the token Evaluation: 0 or N messages required to enter CS No messages if process holds the token Otherwise (N-1) requests, 1 reply synchronization delay – T

Raymond’s tree algorithm Overview: processors are arranged as a logical tree Edges are directed toward the processor that holds the token (called the “holder”, initially the root of tree) Each processor has: A variable holder that points to its neighbor on the directed path toward the holder of the token A FIFO queue called request_q that holds its requests for the token, as well as any requests from neighbors that have requested but haven’t received the token If request_q is non-empty, that implies the node has already sent the request at the head of its queue toward the holder T1 T2 T3 T4 T5 T6 T7

Raymond’s tree algorithm Requesting the critical section (CS): When a process wants to enter the CS, but it does not have the token, it: Adds its request to its request_q If its request_q was empty before the addition, it sends a request message along the directed path toward the holder If the request_q was not empty, it’s already made a request, and has to wait When a process in the path between the requesting process and the holder receives the request message, it < same as above > When the holder receives a request message, it Sends the token (in a message) toward the requesting process Sets its holder variable to point toward that process (toward the new holder)

Raymond’s tree algorithm Requesting the CS (cont.): When a process in the path between the holder and the requesting process receives the token, it Deletes the top entry (the most current requesting process) from its request_q Sends the token toward the process referenced by the deleted entry, and sets its holder variable to point toward that process If its request_q is not empty after this deletion, it sends a request message along the directed path toward the new holder (pointed to by the updated holder variable) Executing the CS: A process can enter the CS when it receives the token and its own entry is at the top of its request_q It deletes the top entry from the request_q, and enters the CS

Raymond’s tree algorithm Releasing the CS: When a process leaves the CS If its request_q is not empty (meaning a process has requested the token from it), it: Deletes the top entry from its request_q Sends the token toward the process referenced by the deleted entry, and sets its holder variable to point toward that process If its request_q is not empty after this deletion (meaning more than one process has requested the token from it), it sends a request message along the directed path toward the new holder (pointed to by the updated holder variable) greedy variant – a process may execute the CS if it has the token even if it is not at the top of the queue. How does this variant affect Raymond’s alg.?