COP 5611, Operating Systems, Spring 2003
Department of Computer Science, Florida State University
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Points: 100
Due: Week 9, Thursday, March 6, 2003
Maximum Team Size: 2
Purpose: To know how to implement distributed mutual exclusion and experience technical and design issues in distributed systems.
Background: Mutual exclusion is an important problem in operating system design. Whenever shared resources are accessed concurrently by several processes, either centralized or distributed, mutual exclusion to critical sections of all processes must be guaranteed; otherwise, inconsistency of the data may result and the outcome of the processes may depend on the order of the execution.
In traditional operating systems, with shared memory and special instructions, mutual exclusion can be solved using semaphores and other methods. In distributed systems, due to the lack of shared memory and global clock, distributed mutual exclusion is technically more involving as the processes can only rely on exchanging messages as a means for communication.
There exist several classes of distributed mutual exclusion algorithms, including centralized, token based and non-token based. In this programming project, you will explore how to solve the distributed mutual exclusion problem using the Lamport’s algorithm (and the Richart-Agrawala’s algorithm as an extra credit option). You will need to design communication protocols between processes, design data structures used by the involved processes, and overcome technical problems. Because of the difficult nature of distributed algorithms, you can work as a team with at most two team members on each team.
Server and Client Processes: To simulate a distributed application environment where distributed resources are shared among processes, in this project there will be three types of processes. There is a bank account server which acts like a central database system and there will be several bank business offices which perform balance transfers between bank accounts. Each bank office will be modeled by two processes: a bank office client and a bank office mutual exclusion control process.
· Multithreaded Bank Account Server
The functionality of the bank account server is to keep the bank accounts and respond to client’s requests. The server must respond at least to the following client requests.
- Current balance request of a particular account. For this request, the server simply writes back the current balance of the requested account.
- Balance updating request. For this request, the server changes the requested account balance and sends an acknowledgement.
- Connection close request. Upon receiving this request, the server sends an acknowledgement and closes the connection.
Note there will be no mutual exclusion implemented on this server.
· Bank Business Office Clients
- Transaction preparation (Simulated by generating a pair of accounts and the amount to be transferred (which is a random number between 1 and 50)).
- Doing transaction. This includes 1) getting the current balance of the account to be transferred from; 2) updating its balance; 3) sleeping for a random number of seconds (between 1 and 10); 4) getting the current balance of the account to be transferred to; 5) updating its balance. Note that this is the critical section as shared resources (bank accounts) are accessed.
· Bank Office Mutual Exclusion Control Processes
These processes are responsible for implementing the distributed mutual exclusion algorithm(s). Note that each process involves sending and receiving messages required by the distributed mutual exclusion algorithm(s). Here the services of these processes depend on the algorithm to be used. For the Lamport’s distributed mutual exclusion algorithm, each process needs to do the following.
- Critical Section Entering Request. Here there are two different cases: the request from other offices and the request from its associated office.
- Critical Section Releasing Request. Also there are two different cases: the request from other offices and the request from its associated office.
Assignment: Implement the three programs based on TCP.
After the programming is done, test your programs using (at least) the following combinations.
(1) All of programs run on one of the “program” machines (that is, all the programs run on the same machine).
(2) The bank account server runs on one of the “linprog” machines; half of the others run on at least two different “program” machines and the rest run on at least two different “linprog” machines.
(3) The bank account server runs on one of the “program” machines; half of the others run on at least two different “program” machines and the rest run on at least two different “linprog” machines.
For each combination, you need to demonstrate two (three if you choose to do the extra credit option) different cases: without and with mutual exclusion (with different algorithms). For the first case (without mutual exclusion), you need to show that the results are incorrect (e.g., the total balance is NOT kept as a constant). For the second case (with mutual exclusion, but otherwise with the same parameters), the problem of data inconsistency and race condition is solved.
Submission:
Hardcopy is required for submission and each team only needs to submit one report, specifying the contributions of each team member. Note that all the team members need to understand all the issues and you may be tested in the exams.
Extra Credit (15 %): Please state clearly in your report if you have implemented the following extra credit option.
The Lamport’s algorithm is discussed in Sect. 6.6 and the Richart-Agrawala’s algorithm is covered in Sect. 6.7 both in the textbook. This project can be naturally broken into three parts. The bank account server and bank office clients are relatively straightforward to implement while the bank office mutual exclusion control processes are the most difficult part. As the programs need to know the system’s setting, a common parameter file that specifies the necessary information is highly recommended, which will ease the testing. A parameter file should include the following information.
- Bank-Accounts: Followed by two values to specify how many accounts in the system (starting from 1) and the initial account balance for all the accounts. For example,
Bank-Accounts 10 100
means that there will be ten accounts (with account numbers from 1-10) with initial balance of 100 for all of them.
- Bank-Server: Followed by two values, specifying the server’s IP and port number. For example,
Bank-Server 128.186.120.53 1281
specifies that the bank-server will be on program1 at port 1281.
- Bank-Offices: Followed by a number specifying the number of offices in the system and entries for each bank-office. Each bank-office entry includes bank-office-ID (a unique integer), its IP, port number, and the total number of transactions to be performed. The ID will also be used to impose a total ordering relation among processes. For example,
Bank-Offices 4
1 128.186.120.53 1282 100
2 128.186.120.54 1282 200
3 128.186.120.33 1284 100
4 128.186.120.34 1285 200
This specifies that there will be four bank offices involved, two on “programs” (“program1” and “program2”) and two on “linprog” (“linprog1” and “linprog2”). Offices 1 and 3 will perform 100 transactions while the other two will perform 200 transactions.
- Mutual-Exclusion: Followed by an integer, specifying the mutual exclusion algorithm to be used. If the value is 0, there will be no mutual exclusion control; otherwise, mutual exclusion will be used. For extra credit, if the value is 2, the Ricart-Agrawala’s algorithm is used; otherwise, the default Lamport’s algorithm will be used.
To keep on schedule and avoid the last minute panic, you need to start the project way in advance. As the projects can be broken naturally into three parts, it is a good practice to develop and test them one by one. For this project, a natural development ordering is 1) Bank Account Server first; 2) Bank Office Client Program second. At this point, you should have a working system with no mutual exclusion. Then you develop the Bank Office Mutual Exclusion Control Program and integrate it with the Bank Office Client program.
As a reminder, you should test/run your programs only on “programs” and “linprog” as the programs may involve creating threads/processes. Violations may result in losing some of the privileges you have.