CS 453/552: Operating Systems
Programming Assignment 3 (100/110 points)
Producers/Consumers Monitor
Due Date (on class home page)
1
Introduction
In this project, we will solve the producers-consumers problem using monitors. As part of the
assignment, you will get to create a thread-safe version of your linked-list code!
You will need to have the generic shared library version of your linked list code for this project.
2
Specification
2.1
Producers and Consumers using Monitors (100 points)
We will simulate a size-bounded queue (implemented as a doubly-linked list with a limit on maximum size) being shared by multiple producers and multiple consumers running simultaneously.
Suppose we have m producers and n consumers (where m and n are supplied as command line
arguments). The initial main process creates a queue data structure. Make this queue global so
all threads can access it. Then the main process will create m producer threads and n consumer
threads.
We will fix the number of items each producer produces (as a command line argument). Then we
will keep track of how many items each consumer actually consumed. At the end of the program,
we print out the total number of items produced versus the total number of items consumed. These
two numbers should be the same unless the program has race conditions.
The items are a structure that contain an unique id (basically number the items 1, 2, 3, . . . as they
are entered in the queue) and also contains the index of the producer that created it.
2.1.1
Approach
• A template program has been provided for you to use as a starting point. The program is in
the examples repository at lab/projects/producers-consumers and the main file is called
pc.c. The directory also contains a relevant Makefile that you should use.
• First, you will need to create a monitor version of your doubly linked list to use in this
project. An additional feature we will add to it is the ability to set the maximum size
of the list in the constructor. You will be using the PThread mutexes and PThread condition variables to implement the monitor version of your doubly linked list. Relevant man
pages are pthread mutex init, pthread mutex lock, pthread mutex unlock, pthread cond init,
pthread cond wait, pthread cond signal.
• Please create a separate version of your linked list that implments a monitor. You should
make a copy of your p0 list code inside the p3 code and name it thread-safe-list. Modify
the Makefile to build this version of your list library for use with the producer-consumer
test program.
• Then the producer/consumer threads test program will use the monitor version of the doubly
linked list to run the simulation. To test your monitor version, we will have the producers randomly insert new items at the front or back of the queue. Similarly the consumers
randomly remove items from the front or back of the queue.
2.1.2
Notes on testing
• You should not modify the test program pc.c. Adjust your list implementation if needed. Your
list implementation will need to be fully generic. You will need to add an additional function
to your list class that allows the simulation to be stopped after the producers are done. This
function is called finishUp.
• When testing your program limit the number of threads to less than ten and number of items
produced per producer to less than ten thousand to avoid overloading onyx. At home you
can do whatever you want :-)
• Run the program several times for the same input arguments. Verify that the results do not
vary.
• Comment out the output statements. See if that changes the results for the number of items
consumed versus produced.
• Use the testing script provided in the assignment folder.
2.2
Multiple Queues (10 points)
Required for graduate students. Optional for undergraduates.
Create another version of the testing program pc.c and call it pc-mq.c and adjust the Makefile
accordingly.
Add another command line argument that allows the user to specify the number of queues (with
the same size limit on each). The number of queues should be the first command line argument.
Usage: pc-mq <#queues> <poolsize> <#items/producer> <#producers>
<#consumers> <sleep interval(microsecs)
Now modify your the testing code to create multiple queues and have the producers/consumers
access the queues in round-robin fashion, which is explained below.
Suppose we have k queues. Then if the ith queue is full, the producer moves on to the (i+1) mod kth
queue. Similarly if the ith queue is empty, the consumer moves on to the (i + 1) mod kth queue
Testing would be the same as before. You could also informally test if multiple queues allows the
producers and consumers to get their work done faster although that would depend on the mix of
the work being simulated.
2
3
Required Files for Submission
Include a README file in the usual format. Please submit the files below. Your final executable
should be in your top level folder.
• README, Item.c Item.h Makefile pc.c test.sh
• Your linked list files
4
Submitting the Project
Open up a terminal or console and navigate to the backpack folder for the class. Navigate to
the subdirectory that contains the source files that you worked on for the project/homework.
Suppose that we are submitting three files README.md, main.c and utility.c and one folder
named include.
• Clean up your directory
make clean
• Remove any other unnecessary files that were generated by you or the auto-grader.
• Add all your changes to Git (this would be specific to your project)
git add main.c utility.c include/ README.md
• Commit your changes to Git
git commit -a -m "Finished project p3"
• Create a new branch for you code
git branch p3_branch
• Switch to working with this new branch
git checkout p3_branch
(You can do both steps in one command with git checkout -b p3_branch )
• Push your files to the Backpack server
git push origin p3_branch
• Switch back to the master branch
git checkout master
• Here is an example workflow for submitting your project. Replace p1 with p3 in the example
below.
[spanter@valkyrie shane(master) ]$ git checkout -b p1_branch
Switched to a new branch ’p1_branch’
[spanter@valkyrie shane(p1_branch) ]$ git push origin p1_branch
3
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:shane
* [new branch]
p1_branch -> p1_branch
[spanter@valkyrie shane(p1_branch) ]$ git checkout master
Switched to branch ’master’
Your branch is up-to-date with ’origin/master’.
• Help! I want to submit my code again! No problem just checkout the branch and hack away!
[spanter@valkyrie shane(master) ]$ git branch -r
origin/HEAD -> origin/master
origin/master
origin/p1_branch
[spanter@valkyrie shane(master) ]$ git checkout p1_branch
Branch p1_branch set up to track remote branch p1_branch from origin.
Switched to a new branch ’p1_branch’
[spanter@valkyrie shane(p1_branch) ]$ touch foo.txt
[spanter@valkyrie shane(p1_branch) ]$ git add foo.txt
[spanter@valkyrie shane(p1_branch) ]$ git commit -am "Adding change to branch"
[p1_branch 1e32709] Adding change to branch
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo.txt
[spanter@valkyrie shane(p1_branch) ]$ git push origin p1_branch
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 286 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:shane
36139d1..1e32709 p1_branch -> p1_branch
[spanter@valkyrie shane(p1_branch) ]$ git checkout master
Switched to branch ’master’
Your branch is up-to-date with ’origin/master’.
[spanter@valkyrie shane(master) ]$
• We highly recommend reading the section on branches from the Git book here: Git Branches
in a Nutshell
4