CMPS 555 - Spring 2001
Principles of Operating System Theory
Project Page

URL: http://www.cacs.usl.edu/~cxg9789/cs555/
TA: Cengiz Gunay
Email: cengiz@ull.edu
Office: CC440
Office Hrs: Tu, Th 3:00-4:30 (or by appointment)
Phone: x2-5079

UPDATED FREQUENTLY
Check for the last modification date at the bottom of the page and change list.

Contents

Project Requirements

 The class requirements include a project of application of mutual exclusion in distributed and concurrent systems. The Lamport's algorithm and Ricart-Agrawala algorithm should be used to achieve mutual exclusion. They are explained in the textbook [1] at pages 127-130.

Groups of two students are required for this project. One should be responsible for implementation using threads and the other using distributed computing of the problem described below using the two algorithms.

Students are free to choose whichever programming language (C, C++, Java, etc.) and distributed environment (RMI, PVM, MPI, etc.) for implementation, though we suggest using the Java language and its RMI application interface for distributed computing. We have provided links below to help the students learn more about Java and RMI. Students willing to use alternative programming languages and distributed environments should inform the TA first.

Problem Description

The Bank

Assume there are n bank tellers in a city and there are m clients of this bank. Each client has an account balance in the bank.

Each teller keeps a copy of the record of the account balances of all the clients. There is no central record of client balances in this bank. They have all the data in distributed locations for, say, speed and security reasons.

Transactions

During the working hours, clients may come to any teller and make a balance transfer from one account to another. We assume a client has the authority to initiate a transfer as long as he owns one of the accounts.

A balance transfer should be executed mutually exclusive among all n tellers. At the end of the transaction, all balance records in each teller should be identical. Before a transaction, the teller should make sure no other teller is engaged in a transfer involving any of the two accounts. After the transaction the teller should update the other tellers about the balance transfer. It should only send a message giving the details of the current transfer and should refrain from sending all account balance information.

The Mutual Exclusion Algorithm

Lamport's mutual exclusion procedure for distributed systems explained in the textbook [1] at pages 127-130, should be modified and used to ensure integrity of the bank accounts. Then, a similar algorithm, the Ricart-Agrawala algorithm should be used to improve performance. Lamport's logical clock can be implemented for the timestamps in communications. (see this note)

The Task

You are going to simulate one working day for the bank. Your program should be able to take preformatted inputs indicating the transactions to be executed at each teller and produce the expected output for verification of correctness.

Termination

At the end of the day (after all transactions at all the tellers have ended) the tellers should properly shut down. In order to ensure this, you have to use the following distributed termination detection algorithm:

At the end of the day, after proper termination, all account balance records in all tellers should be identical if mutual exclusion is ensured during transactions. No balance should go below 0 at any time during transactions.

Implementation Issues

First you should consider the case where there are n=3 tellers and m=10 accounts.

You must write two separate programs, one by each group member:

Distributed implementation:

Each teller should be put on a separate workstation.

Communication between tellers should be done by using message passing (for example using Java's RMI services, or if you prefer C/C++ you can achieve it using UNIX RPC, or messaging environments like PVM, MPI.).

Concurrent implementation on single workstation:

Each teller should be made a separate running thread with its own data structures.

Communication between tellers can be done calling thread functions in a mutually exclusive fashion. You can use the constructs in the language you're using to achieve this. (synchronized blocks in Java and use of semaphores in C/C++.)

Input/Output Formats

Input files

Each teller should be able to process transactions from an input file in the following tabular format: 
      Time	From acct.	To acct.	Amount
      -----	----------	----------	----------
      1		3		5		12
      2		5		1		4
      ...

Output files

Each teller should:

Output at each balance transfer, the balance of the accounts involved before and after the transaction.

Output at the end of the day, the balances of all accounts in the following format: 

	Acct.	Balance
	-----	-------
	1	34
	2	45
	...

Sample files

Assume the balances of all accounts are initialized to 50. Using the input files A, B and C for the three tellers respectively will result in this output file.

Another set of input files with timestamps starting from 0: A, B and C and output.

Note about times in input file: You might have to increment the logical clocks in each teller until they start processing the events in their files only in the case of a deadlock, ie. if no tellers have a job to handle and they are waiting for others to do something. You can increment the logical clock by ONE after waiting for a whole second without message traffic, which will be the deadlock detection condition.

What to Turn In

 You need to write a 5-10 page report about the implementation you made and the statistics you collected about the performances of the algorithms implemented.

In order to check for the validity of your program, you should process transactions from separate input files (see above) for each teller for the case of n=3 tellers and m=10 balances.

On the other hand, for collecting statistics, you should not use input files. The tellers should randomly create transactions for a number of times and then terminate. You can limit the number of transactions to 10. Measure running times for both algorithms for cases of n=3,4,5,... and m=10,50,100,500,... . Plot graphs and provide tables showing your results.

Explain your results and discuss if they are in accord with the predictions.

Explain how your program works. Provide two sections, authored by each group member respectively. Specify who did which part of the program. Include the problems that you've encountered during the implementation.

Since group members will use the same algorithm to achieve the objective of the project, the report should include a common part explaining how the problem is solved.

Turn in well documented source code, preferably printed using a2ps. If you're using Java, a javadoc output is preferred.

Links for Java Remote Method Invocation (RMI)

You should create a .java.policy file in your home directory in order to give necessary permissions to use Java RMI.

From Sun Microsystems, Inc.:

Links for Java Features for Multi-Threaded Programming and Mutual Exclusion

Due Date and Demo Schedule

 The final report for the project is due May 1st. Late submissions will receive penalties. You can update your code until your scheduled demo time provided that you hand in a changes report at time of your demo. Report and hardcopies can be turned in to my office, CC 440 (you can slip them under the door).

Demos will be taken during 1-5pm from May 2nd (wednesday) through May 4th (friday). Please sign up for an available slot for your group on the sheet posted on the door of CC 440.

Requests for demos out of these days and/or times can be negotiated if you contact the TA. However, the last day to demo is friday, May 4th.

Changes to This Page

References
  1. M. Singhal, N.G. Shivaratri. Advanced Concepts in Operating Systems. Mc Graw Hill Publishing, 1994.
* Java v1.3 is currently not available in neither UCS or CACS networks. Click on one of the links to make a wish to the administrator.
Feedbacks are welcome to:
Cengiz Gunay
Last modified: Fri Dec 3 16:01:20 EST 2004