Be Resourceful

Overview

In the source code folder  you will find some C code that is the beginning of an experiment with resource allocation and interprocess communication.  

There are three programs here :

1. msgtest.c makes a message queue (man mq_overview for help), and sends 100 messages to it (as it can). 
2. msgget.c opens the message queue and reads messages from it until it has read 100 of them and then removes the message queue and exits.
3. driver.c is set up to allocate resources and then use them.   Except it doesn't actually use them, instead it just waits for some given time.  Notice that there are two ways to wait (csleep and usleep)  that are quite different and will not sleep for the same amount of time given the same parameters - that is, csleep(1000) and usleep(1000) will not return after the same amount of time.

Note that msgtest and msgget are not part of your final assignment, but are simply example code to show you how to use the message queuing interface ("man mq_overview"). 

The resources (in driver.c) are just numbers here, but should be treated as though they are real resources that can only be used by one process at a time.  The current driver program uses acquire and release to manage resources.  Since this is a single process, there is no resource contention, and neither acquire nor release actually need to do anything. 

What to do

You should modify driver.c and construct a new c program "worker.c".  The driver program is already set up to take flags to specify the number of workers, the number of resources and the number of tasks to run and the type of sleep to use. 

When your modified driver runs, it should start the requested number of workers (from the --worker-count command line argument), and run the requested number of tasks in those workers, with the resources specified.  Note that each worker should start and then run in a loop that waits for a message on the message queue, parses that message as needed, acquires the needed resources, sleeps, and then frees the resources.

You should probably use one message queue per worker - although there are different ways to manage this.

I'd suggest you start with a single worker and make sure that you can send and receive the messages as needed.   Once that works, try running with multiple workers and be sure that only one worker at a time is ever using any given resource (so, for instance, you should never have two workers using resource 17 at the same time).   You should provide a make target that tests this.

You should also provide a make target "cleanup" that ensures that all processes started are stopped, and that any ipc resources used are also cleaned up.

Once this is all running, do some tests and write up the results.  In particular, given the same parameters for which sleep to use and the same number of tasks, and with at least 50 resources, try running different numbers of workers.  You should do this with 1,2,3..20 workers (or as many as you can).  When you run it with just a single worker process, the run should take at least 5 minutes.  Plot the results and explain what you see.  If you have access to both a single cpu and multiple cpu machine, try it on both and explain any differences.  If you have time, you might also compare the difference between using csleep and usleep - since the sleep times are not directly comparable, you'll need to compare the shape of the graphs.

What to Submit

Submit all of your code (including any scripts you might use to run tests) and your write up. 

How you will be graded

While your grade will depend on your code, you should consider that the experimental part of the assignment and the write up are the most important parts of the assignment.

As usual you will be graded on your code.    In particular, you should ensure that your test scripts (or the code itself) properly cleans up on a successful run, but you also need a way to clean up if the program crashes. 

You will also be graded on your experiments and write up.    The ideal will be to find an interesting way to divide up the worker processes to best even out resource use, to run the program for a reasonable number of trials with different numbers of worker processes using both sleep types and to nicely plot the output with good explanations of those plots.   Running the tests (completely, with good explanations) on processors with different numbers of cores will be given extra consideration in grading - but if your basic work is not complete, this is unlikely to make much difference.