Multithreading synchronization(repost)

Peruttu Julkaistu May 11, 2009 Maksettu toimituksen yhteydessä
Peruttu Maksettu toimituksen yhteydessä

**Please note that this is an EMERGENCY project and the deadline is 11 PM, 12th May US Eastern Standard Time. The project will be in Linux using C. The server code will be provided. To successfully complete the project, you will need to add the following features to the code: 1. Add synchronization so that when running in multithreaded mode, there are never race conditions and use helgrind (if possible) to detect race conditions. Otherwise, simply ensure that the program behaves as expected in multithreaded mode and does not deadlock (hang). (When testing the synchronization, do not use -s). Please note that you do NOT need to implement any clients from scratch. You need to only check that the functions already implemented are re-entrant so that they can run in multi-threaded mode. You do NOT have to make a multi threaded server. 2. Do Profiling using gprof and a write up of the results, 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 comparision.

Optional for additional 10% bonus pay: 3. Pick an aspect of the code that influences its performance, after profiling so that you have a clear picture of what area to target. Improve the performance of the code with some optimization or improved coding, and provide an additional writeup explaining what you changed and showing its impact on performance.**

## Deliverables

Please read the whole problem statement carefully.

Background information:

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.** The code already provided with this post, avoided this concern by running the server in the other, single-threaded mode, passing it the -s option. When testing your synchronization after adding code, 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.

Two server codes ( running in single threaded mode with no synchronization and file backing) are provided and have the following functionality already:

* Provides complete filesystem semantics, including multiple, hierarchical directories, creation and deletion of files and directories, and accurate statistics such as file sizes and hard link counts. [ [have ignored creating hard links, keeping track of modification times, managing permissions (directories can all be mode 0755 and files can all be mode 0644), et cetera]

* Used some sort of tree-like in-memory indexing structure internally to support sparse petabyte-sized files. [need not back the structure on disk anywhere, it can be entirely in-memory for this portion of the project. no synchronization or possible race conditions handled, because it is running in single-threaded mode.

The codes are heavily documented and should be fairly straightforward to follow. Feel free to use either one of the codes to add the additional functionality.

Other material required:

1. FUSE: File System in Userspace ([url removed, login to view])[

][1]

2. Example of hello world file system ([url removed, login to view])[

][2]

steps for mounting fuse:

1. Create a directory to hold your project. Inside that directory create a file called Makefile(or the one provided with the code) with the following contents:

CFLAGS = -g -Wall `pkg-config --cflags fuse` -DFUSE_USE_VERSION=26

LDFLAGS = `pkg-config --libs fuse`

all: server

.PHONY: clean

clean:

rm -f server

Make sure that the space before

rm is a single tab character, not spaces.

2. Create an initial, trivial server. E.g.: Start with the [hello world][3] filesystem; put your code in a file called server.c.

3. Run make to compile the server. Create a directory called mnt to serve as a “mount point??. Assuming the compilation succeeded, run ./server mnt and play around with the resulting filesystem that appears in mnt. When done, run fusermount -u mnt to unmount the filesystem.

Also attached is a test file that I hope will make things much clearer and will help you test your synchronized code:

Test script to test a multi threaded file system (only assuming a lock on the data).

Using these files you can vary many parameters such as the number of files, threads per file, write sizes, and file sizes.

Attached is the code in the zip file.

An example run is:

./[url removed, login to view] -c -f 2 -l 10 -n 30 -o 100 -t 16 | less

This will show the commands run, create 2 files, writing in blocks of max size=10, 30 iterations per thread, writing at a max offset of 100, and 16 thread per file.

The output will give you an idea of how much they had overlapping reads and writes.

You can see how much overlap there was between a read and a write by the success rates. 100% means none and 0% means all. You should expect the success rate to fall as you have more threads on the same file. If you FS does not work you would expect the script to never return because it deadlocked and hung forever.

[

][2]

tekniikka Linux MySQL Odd Jobs PHP Projektinhallinta Tietojärjestelmäarkkitehtuuri Ohjelmistojen testaus

Projektin tunnus: #3873400

Tietoa projektista

Etäprojekti Aktiivinen May 20, 2009