Buffer management In this project you will implement a multi threaded buffer manager to reduce the number of disk accesses. Instead of going to the disk on each read/write, you will first try to meet the requests from the cache that you will implement. Your implementation should support the following interface functions which the test programs will call.

buffer_init(int maxblocks, int blocksize, int buffsize);
hit = buffer_read(int blockno, char *dest);
hit = buffer_write(int blockno, char *src);

The init routine will be called upon startup. maxblocks indicates the total number of blocks in the system, of which only a certain number (limited by buffsize) can be in the cache at any time. The semantics of theread and write functions are obvious. Each of these two routine operates only on the specified block no (only 1 block at a time), and returns whether it was hit or not in the cache. The buffer manager should create a buffer space of the specified buffsize,and include routines to lookup this space efficiently (using hashing mechanisms).

This lookup will be done by the thread calling the buffer_read() and buffer_write() functions, and if found in the cache, these routines will perform the appropriate actions. If not found in the cache, the manager should read the blocks from disk. In order to simulate the disk access, you can maintain a UNIX file (of size maxblocks*blocksize) in your buffer manager, and read and write to the appropriate blocks of this file. Once the block is obtained from this "simulated" disk, you then perform the operations (read/write) in the cache, after updating the appropriate data structures needed for lookup. Note that you can put this block from disk only into a slot that is free.

Your buffer manager should include the following two threads:

flusher : This thread periodically (once in 5 seconds) writes back alldirty block from your cache into the appropriate blocks of the simulateddisk. Note that the blocks will continue to reside in the cache afterthis operation, but will now be clean.

harvester : This thread is normally asleep. It wakes up when (needs tobe implemented with semaphores) the number of "free" blocks in your cachedrops below LOW_WATERMARK. At this point the harvester evicts blocks- in LRU order - from the cache, until the number of "free" blocks reaches HIGH_WATERMARK, at which point it goes back to sleep.

For the specifics and any latest updates make sure you keep checking this web-site for any latest information/updates regarding the project. Also note that the test programs (i.e. the user programs which will exercise the cache system you will implement) will be available here soon. You should make sure that you use the same test programs (the interface should remain the same, and they should be compilable/linkable with your code). You can either work in the same group (as in the earlier projects), or form new groups. Even though you will work in groups of up to three (individual projects are also allowed), each of you should be fully familiar with the entire code. You should also ensure that there is a fair division of labor between the members.

The project report is due in class on April 25. The code needs to be submitted using the turning procedure(to be announced) on the due date before 02:00PM and there will be a 20% deduction for delays upto 24 hours and 40% deduction for delays upto 48 hours. Projects turned in after 48 hours of the posted deadline will not be graded. The report should include (a) a complete listing of your code, (b) a detailed description of your implementation, (c) design decisions and assumptions (with justifications) that you may have made, (c) breakdown of the contribution of each member of a team. You need to set up an appointment with the TA to demonstrate your implementation and answer a range of questions related to the entire project (even though an individual may have worked on only one part). The TA will use the test programs provided here for testing your code and may use other test programs as well.

Lab Usage :