- Type
- Quiz
- Course
- CS407 Routing and Switching
- Size
- PDF 515 KB
- Updated
- 23 Oct 2026
You get 3 free files a day on the website. Add the Chrome extensionSign in with the extension for 30 a day.
Preview text
Text from pages 2, 3, 4 of 7. Download the file for all 7 pages.
Module 6
Distributed mutual exclusion – central server algorithm – ring based algorithmMaekawa's voting algorithm –Election: Ring -based election algorithm – Bully algorithm
6.1 DISTRIBUTED MUTUAL EXCLUSION
Distributed processes often need to coordinate their activities. If a collection of processes share a resource or collection of resources, then often mutual exclusion is required to prevent interference and ensure consistency when accessing the resources. The application-level protocol for executing a critical section is as follows: enter(): enter critical section – block if necessary resourceAccesses() : access shared resources in critical section exit(): leave critical section – other processes may now enter
Our essential requirements for mutual exclusion are as follows: ME1: (safety) At most one process may execute in the critical section (CS) at a time. ME2: (liveness) Requests to enter and exit the critical section eventually succeed. ME2 implies freedom from both deadlock and starvation. A deadlock would involve two or more of the processes becoming stuck indefinitely while attempting to enter or exit the critical section, by virtue of their mutual interdependence. But even without a deadlock, a poor algorithm might lead to starvation: the indefinite postponement of entry for a process that has requested it. The absence of starvation is a fairness condition. ME3: ( ordering) If one request to enter the CS happened-before another, then entry to the CS is granted in that order.
We evaluate the performance of algorithms for mutual exclusion according to the following criteria:
- the bandwidth consumed,
- the client delay incurred by a process at each entry and exit operation;
- the algorithm’s effect upon the throughput of the system
Algorithms for mutual exclusion
A central server algorithm
A central server algorithm
The simplest way to achieve mutual exclusion is to employ a server that grants permission to enter the critical section. To enter a critical section, a process sends a request message to he server and awaits a reply from it. Conceptually, the reply constitutes a token signifying permission to enter the critical section. If no other process has the token at the time of the request, then the server replies immediately, granting the token. If the token is currently held by another process, then the server does not reply, but queues the request. When a process exits the critical section, it sends a message to the server, giving it back the token.
Four process p1, p2, p3, p4 p1no need to enter critical section (CS) p4 & p2 send request the token to enter CS But p3 is accessing CS. So p4 & p2 enter the queue. P3 released its token p4 get the permission to enter CS After p4 released , permission grant to p2
One of the simplest ways to arrange mutual exclusion between the N processes without requiring an additional process is to arrange them in a logical ring. This requires only that each process p i has a communication channel to the next process in the ring, p (i + 1 )mod N . The idea is that exclusion is conferred by obtaining a token in the form of a message passed from process to process in a single directionclockwise. If a process does not require to enter the critical section when it receives the token, then it immediately forwards the token to its neighbour. A process that requires the token waits until it receives it, but retains it. To exit the critical section, the process sends the token on to its neighbour.
Ricart and Agrawala [1981] developed an algorithm to implement mutual exclusion between N peer processes that is based upon multicast. The basic idea is that processes that require entry to a critical section multicast a request message, and can enter it only when all the other processes have replied to this message. The conditions under which a process replies to a request are designed to ensure that conditions ME1–ME3 are met. To illustrate the algorithm, consider a situation involving three processes, p 1 , p 2 and p 3. p 3 is not interested in entering the critical section p 1 and p 2 request entry concurrently. Timestamp of p 1 ’s request is 41, and that of p 2 is 34 p 3 receives their requests, it replies immediately p 2 receives p 1 ’s request, it finds that its own request has the lower timestamp and so does not reply p 1 finds that p 2 ’s request has a lower timestamp than that of its own request and so replies immediately. On receiving this second reply, p 2 can enter the critical section. When p 2 exits the critical section, it will reply to p 1 ’s request and so grant it entry.
Maekawa observed that in order for a process to enter a critical section, it is not necessary for all of its peers to grant it access. Processes need only obtain permission to enter from subsets of their peers. A subset contain { p1, p2, p3, p4 }, if p1 wants to enter CS it need only permission from p2, p3 and p4. ie. A process pi send request msg to all other k-1 member of vi. This algorithm can tolerate some process crash failure. If a crashed process is not in a voting set then its
Related CS407 files
All CS407 files →- CS407 Handouts Set 3 by VUBuddy Handout PDF 8.4 MB
- CS407 Midterm Past Papers 2025 Midterm PDF 998 KB
- CS407 Highlighted Handouts Highlighted PDF 8.4 MB
- CS407 Midterm MCQs August 2024 by Miss Mehwish Midterm PDF 571 KB
- CS407 Final Term MCQs by Aissh Khan Final term PDF 283 KB
- CS407 Handouts Handout PDF 8 MB
Get more out of VUBuddy, for free
- Unlimited downloads
- The explanation behind every MCQ answer
- Study offline on slow data
- 30 downloads a day instead of 3
- Sign in and buy Pro Semester here
One Pro Semester membership works in both the extension and the app.