CS4411 Programming Assignment 3: Synchronization and Performance

Due May 12.

This is the second half of the semester project, in which you will incorporate synchronization and gain experience profiling and addressing performance.

Rembember that FUSE can operate in two modes with respect to threading. In multi-threaded mode, the default, FUSE will spawn a pool of worker threads to handle incoming requests. It will do this totally transparently, on your behalf; the only thing you need to know is that your functions must be re-entrant. You have avoided this concern for the first half of the project, by running your server in the other, single-threaded mode, passing it the -s option. When testing your synchronization, do NOT use -s. There will never be any race conditions in single-threaded mode, and your synchronization will appear to work correctly even if it is broken.

Requirements

You must do two things for this assignment:

• Add synchronization to your SPBFS server, so that when running in multithreaded mode there are never race conditions. You may use helgrind to detect race conditions, if you have access to it; otherwise, simply ensure that your program behaves as expected in multithreading mode and does not deadlock (hang). This code will not be tested for advanced features that were required in the first part of the project, but must function under workloads that will exercise synchronization. Update: There is no working version of helgrind on schroeder, so its use is not required.
• Profile your code using gprof, and write up the results in about one page, describing the performance characteristics of your server. Try multiple different workloads, spread out over multiple files or concentrated in one for example. In addition, provide the actual output of the profiler for comparison.

For extra credit, you may:

• Pick an aspect of your code that influences its performance, after profiling so that you have a clear picture of what area to target. Improve the performance of your code with some optimization or improved coding, and submit an additional write-up explaining what you changed and showing its impact on performance, as shown by additional profiling of the improved server compared to your original write-up. If your optimization actually does not improve performance, that is okay; instead write up what you expected, and what happened instead. Try to provide some insight.