Description
Goal
The goal of this assignment is to give you experience writing concurrent programs. Writing
concurrent code that works correctly is hard. Debugging concurrent code that doesn’t work
correctly is much harder. These skills are becoming increasing important. This assignment
introduces you to this set of challenges by having you solve a number of small isolated
concurrency problems and then larger concurrent programming problems.
What to Do
In Part 1, you will solve some simple, isolated concurrency problems and one larger problem, the
classic bounded-buffer, producer-consumer problem.
In Part 2, you will solve two additional, well-know concurrency problems using uthreads,
mutexes and condition variables and then solve the bounded-buffer problem from Part 1 (and the
others from this part for Bonus) using semaphores. The first is a well known problem and the
second is our variation of somewhat-less well-know problem from a wonderful free book called
The Little Book of Semaphores by Allen B. Downey. You can download the book if you like, but
it is not necessary (and probably not that helpful) for this assignment. While these problems are
toys, they were designed to model specific types of real-world synchronization problems that
show up in real concurrent systems such as operating systems and video games, etc.
For each part, your program will consist of a solution to the concurrency puzzle and a test
harness that creates a set of threads and instruments your code to collect information that you can
use to convince yourself (and us) that you have implemented the problem correctly. Bugs will
either be in the form of incorrect results (i.e., violating the stated constraints) or deadlock (i.e.,
your program hangs). The problems are kept as simple as possible.
The code you need for this assignment is in www.ugrad.cs.ubc.ca/~cs213/cur/assignments/a10/
code.zip. There you will find the complete uthread package, including the implementation of
monitors and condition variables and semaphores. You will also find a Makefile that you will
use to build the various parts of this assignment and skeleton files for each of the questions with
some parts implemented for you and some parts, listed as TODO, left for you.
NOTE: Synchronization bugs introduce non-determinism into programs, which means that they
may produce different results each time they are run, even on the exact same input. This also
means that a program with a synchronization bug might execute correctly sometimes and so to
be sure that your a program is bug free it is necessary to execute it many times. You must do
take this step when testing your code for this assignment. The Unix command-line shells
provides ways to automate this task; you might find it useful to investigate how to do this.
For example, in tcsh (i.e., the tee shell) you can type this to execute the program q1 100 times.
repeat 100 ./q1
And in the bash shell:
for n in {1..4}; do ./q1; done
Part 1
Question 1.1: Simple Thread Ordering with Join [5%]
Modify the program part1/q1.c by adding calls to uthread_join (and making no other
changes) so that it always prints the lines “zero” to “three” in order; i.e., its output must
always be the following.
zero
one
two
three
——
Question 1.2: Simple Mutual Exclusion [5%]
Modify the program part1/q2.c to use a mutex so that the program is free of race conditions
(i.e., so that you have guaranteed mutual exclusion for all critical sections in the code) and thus
that it always prints “cnt = 0” when it terminates.
Question 1.3: Simple Thread Rendezvous at a Barrier [5%]
Modify the program part1/q3.c to use a mutex and zero or more condition variables so that
every thread prints “a” before any thread prints “b”. This type of synchronization is called a
barrier and we say that threads all rendezvous at the barrier before any are allowed to continue
past it. Your solution must work for any value of NUM_THREADS. For example, for 3 threads
your program must always output the following.
a
a
a
b
b
b
——
Question 1.4: Thread Ordering with Condition Variables [5%]
Modify the program part1/q4.c to use a mutex and one or more condition variables to order
the threads to produce the same output as your solution to Question 1.1. You solution must use
condition variables to order the threads and it must never deadlock. A correct solution must
consider the issue illustrated by Question 1.3 and also the constraints on the ordering of calls to
signal and wait.
Question 1.5: Producer Consumer [10%]
General Description of the Problem
The producer-consumer problem is a classic. This problem uses a set of threads that add and
remove things from a shared, bounded-size resource pool. Some threads are producers that add
items to the pool and some are consumers that remove items.
Video streaming applications, for example, typically consist of two processes connected by a
shared buffer. The producer fetches video frames from a file or the network, decodes them and
adds them to the buffer. The consumer fetches the decoded frames from the buffer at a
designated rate (e.g., 60 frames per second) and delivers them to the graphics system to be
displayed. The buffer is needed because these two processes do not necessarily run at the same
rate. The producer will sometimes be fast and sometimes slow (depending on network
performance or video-scene complexity). On average it is faster than the consumer, but
sometimes it’s slower.
There are two synchronization issues. First, the resource pool is a shared resource access by
multiple threads and thus the producer and consumer code that accesses it are critical sections.
Synchronization is needed to ensure mutual exclusion for these critical sections.
The second type of synchronization is between producers and consumers. The resource pool has
finite size and so producers must sometimes wait for a consumer to free space in the pool, before
adding new items. Similarly, consumers may sometimes find the pool empty and thus have to
wait for producers to replenish the pool.
What to do
Examine the program part1/pc.c. To keep things simple, the shared resource pool in this
program is just a single integer called items. Set the initial value of items to 0. To add an
item to the pool, increment items by 1. To remove an item, decrement items by 1.
Modify the program this program to use a mutex and condition variables so that the program is
race free and that it satisfies the constraint that 0 <= items <= MAX_ITEMS.
Your code must ensure that items is never less than 0 nor more than MAX_ITEMS. Consumers
may have to wait until there is an item to consume and producers may have to wait until there is
room for a new item. In both cases, implement this waiting using condition variables.
Test your solution with two consumer and two producer threads and the number of processors set
to 4; this is already done for you in pc.c.
Testing
To test your solution, run a large number of iterations of each thread. There are assert
statement(s) in the code that ensure the constraint 0 <= items <= MAX_ITEMS is never
violated; if it is the program will crash.
The program also maintains a histogram of the values that items takes on that prints when the
program terminates. The program prints the histogram when it terminates to give you a window
into what happened during the execution. A correct implementation will have a sort of random
distribution across the values of items, weighted a bit to lower values; and it will be different
each time you run your program. The sum of the counts in the histogram must equal the total
number of changes made to items (i.e., the total number of producer and consumer steps); the
final assert statement checks this constraint.
As with every question in this assignment, run your solution many times to ensure that it
complete correctly each time.
Part 2
Question 2.1: The Cigarette Smokers Problem [30%]
The cigarette smokers problem is a classic synchronization problem, posed by Suhas Patil in
1971. In this problem there are four actors, each represented by a thread, and three resources
required to construct and smoke a cigarette: tobacco, paper, and matches. One of the actors is
the agent and the other three are smokers. The agent has an infinite supply of all of the
resources. Each smoker has an infinite supply of one resource and nothing else; each smoker
possesses a different resource.
The three smoker threads loop attempting to smoke, which requires that they obtain one unit of
both of the resources they do not possess. The agent loops repeatedly, randomly choosing two
ingredients to make available to smokers. Each time the agent does this, one of the three
smokers should be able to achieve its heath-destroying goal. For example, if the agent chose
paper and matches, then the tobacco-possessing smoker can consume these two items, combined
with its own supply of tobacco, to smoke.
This is a simple model of a general resource-management problem that operating systems deal
with in many forms. To ensure that it captures that real problem correctly, the agent has a few
additional constraints placed on it.
The agent is only allowed to communicate by signalling the availability of a resource using a
condition variable. It is not permitted to disclose resource availability in any other way; i.e.,
smokers can not ask the agent what is available. In addition, the agent is not permitted to know
anything about the resource needs of smokers; i.e., the agent can not wakeup a smoker directly.
Finally, each time the agent makes two resources available, it must wait on a condition variable
for a smoker to smoke before it can make any additional resources available.
The problem is tricky because when the agent makes two items available, every smoker thread
can use one of them, but only one can use both. If you aren’t careful, you might create a solution
that results in deadlock. For example, if the agent makes paper and matches available, both the
paper and the matches smokers want one of these, but neither will be able to smoke because
neither has tobacco. But, if either of them does wake up and consume a resource, that will
prevent the tobacco thread from begin able to smoke and thus also prevent the agent from
waking up to deliver additional resources. If this happens, the system is deadlocked; no thread
will be able to make further progress.
Requirements
Implement a deadlock-free solution to the cigarette smokers problem in a C program called
smoke.c; start from the provided file, part2/smoke.c. Use uthreads initialized to use a
single processor (or more if you like).
Create four threads: one for the agent and one for each type of smoker. The agent thread should
loop through a set of iterations. In each iteration it chooses two resources randomly, signals their
condition variables, and then waits on a condition variable that smokers signal when they are
able to smoke. When smoker threads are unable to run they must be waiting on a condition
variable. When a smoker wakes up to find both of the resources it needs, it signals the agent and
goes back to waiting for the next chance to smoke.
The agent must use exactly four condition variables: one for each resource and one to wait for
smokers. The agent must indicate that a resource is available by calling signal on that resource’s
condition variables exactly once. There is no other way for any other part of the system to know
which resources are currently available. The code for the agent is provided for you. You do not
need to change this code, but you can. Just be sure you follow the rules we have just outlined.
You may find it useful to create other threads and add additional condition variables. It is
perfectly fine to do so as long as you follow the constraints imposed on the agent thread. For
example, notice that we have not said how the smokers wait other than to say that they wait on
some condition variable.
To generate a random number in C you can use the procedure random() that is declared in
. It gives you a random integer. You if want a random number between 0 and N,
one way to do that is to use the modulus operator; i.e., random() % N. This procedure returns
random numbers starting with a seed value. Every time you run your program it will by default
use the same seed and so calls to random() will produce the same sequence of random
numbers. That is fine.
Testing
The most common problem with attempts to solve this problem is deadlock. The simplest way
to diagnose this problem initially is to use printf statements in the agent and smokers that tell
you what each is doing. A printf just before and just after every statement that could block
(e.g., every wait) is probably a good idea. If the printing stops before the program does, you
have a deadlock and the last few strings printed should tell you where. Start with one iteration
of the agent. Get that to work, then try more than one.
Be sure that the strings you print with printf end with a new line character (i.e., “\n”),
because printf does not actually print until it sees this character or the program terminates. If
you print without the newline and then your program deadlocks, you will not see the string
printed and you will be confused about where the program deadlocked.
Once you think you’ve got this working, you’ll want to remove the printf’s so that you can
drive the problem through a large number of iterations without being bombarded with output.
One way to do this is to use the C Preprocessor to surround each of your printf statements
with a #ifdef directive like this:
#ifdef VERBOSE
printf (“Tobacco smoker is smoking.\n”);
#endif
A better way — though the more you do with macros the trickier it can get — is to define a
macro called VERBOSE_PRINT that is a printf if VERBOSE is defined and the empty
statement otherwise. To do this, include the following macro definition at the beginning of your
program.
#ifdef VERBOSE
#define VERBOSE_PRINT(S, …) printf (S, ##__VA_ARGS__);
#else
#define VERBOSE_PRINT(S, …) ;
#endif
And then use the macro instead of printf for debugging statements, like this:
VERBOSE_PRINT (“Tobacco smoker is smoking.\n”);
In either case you can now selectively define the VERBOSE macro when you compile your
program to turn diagnostic printf’s on or off.
To turn them on (the program now prints all of the debugging statements)):
gcc -D VERBOSE -std=gnu11 -o smoke smoke.c uthread.c uthread_mutex_cond.c -pthread
To turn them off (the program now prints no debugging statements):
gcc -std=gnu11 -o smoke smoke.c uthread.c uthread_mutex_cond.c -pthread
Testing
Test your program by driving the agent through a large set of iterations. Instrument the agent to
count the expected times each smokers should smoke and instrument each smoker to count the
number of times that each does smoke. Compare these to ensure they match and print them
when the program terminates.
Question 2.2: The Lilliputian Endianness Well Problem [30%]
As has been documented, a great schism befell the land of Lilliput some generations ago when,
following an egg-eating tragedy involving the emperor’s son, it was decreed that all eggs be
eaten small-end first from that time forth — the big end being a far too dangerous place to
commence egg ingestion. But, sadly, as often happens with imperial decrees, some in the
kingdom remained steadfastly committed to the traditional big-end-first manner of eating and as
time passed the endianness schism grew deeper and the risk of conflict more profound.
In the present day, a peace-keeping arrangement has been established that separates Lilliput into
two endianness halves so that the people never risk meeting someone with a different point of
view on the whole egg thing. There is but one problem. Lilliput has only a single well from
which all souls must get their drinking water. A protocol has therefore been established to
control access to the well. It being important to understand the protocol to complete this
question, I will tell it to you now.
There exists a gatekeeper who controls access to the area surrounding the well. The gatekeeper
grants access in such a way as to ensure two things. First, it must never be the case that people
of opposing endianness are at the well at the same time, to avoid the untold calamity that would
surely unfold should either side be confronted with views they don’t share (there is a separate
protocol for social media, but that is of no importance to the gatekeeper). Second, no more than
three people can be in the well area at the same time (a fire-code thing).
The gatekeeper, being noble and fair, ensures that people waiting for water eventually get to use
the well and that their waiting times are roughly uniform, provided that the people at the well
leave on a regular basis. The gatekeeper is also bit of a technocrat and so wants the well to
operate efficiently (i.e., at high capacity), even if this means there’s a bit of queue jumping (i.e.,
sometimes people can enter the well ahead of someone who has been waiting longer than them).
Finally the gatekeeper is wise and has thus devised an exquisite technique to balance the tradeoff
between fairness and efficiency.
Now, it has fallen to you to simulate the Lilliputian well using threads, mutexes, and condition
variables. Every person is a thread. The well is a critical section protected by a mutex. The
gatekeeper is a procedure that each thread calls when attempting to enter the well and when
leaving. When a thread is unable to enter the well it waits on a condition variable. When a
thread leaves the well it delivers whatever signals are necessary to wakeup the thread or threads
that are allowed to enter when it leaves.
Requirements
Implement a solution to the Endianness Well problem in a C program called well.c; start from
the provided file, part2/well.c. Use uthreads initialized to use a single processor (or more
if you like). Use mutexes for mutual exclusion and condition variable for thread signalling.
Create N threads and assign each a randomly chosen endianness. Threads should loop attempting
to enter the well a large, fixed number of times. When a thread is in the well, it should call
uthread_yield() a total of N times and then exit the well. It should then call
uthread_yield() at least another N times before attempting to enter the well again. The
program terminates when every thread has entered the well the specified number of times.
Experiment with different values of N, starting with small numbers while debugging and ending
with a number that is at least twenty.
Testing
Test your program with N=20 and each thread performing a least 100 iterations to ensure that the
two well-occupancy constraints are never violated using an assert statement. Count the
number of times that each of the following occupancy conditions occur: one big endian, two big,
three big, one little, two little, and three little. Print these numbers when the program terminates.
Implement a counter that is incremented each time a thread enters the well. For each thread
entering the well, record the value of the counter when it starts waiting and the value when it
enters the well. Subtract these two numbers to determine the thread’s waiting time and record
this information in a histogram like this.
if (waitingTime < WAITING_HISTOGRAM_SIZE)
waitingHistogram [waitingTime] ++;
else
waitingHistogramOverflow ++;
Declare a large histogram array of size WAITING_HISTOGRAM_SIZE. Print the histogram
and the overflow bucket when the program terminates. If you access the histogram or other test
data from multiple threads be sure to guarantee mutual exclusion for these critical sections.
You will notice that no matter how hard you try to make this fair, if you have enough people
trying to get into the well at the same time, you can’t make it fair for everyone. You will see that
people occasionally end up waiting much longer than it seems they should. The problem is that
there is an inherent unfairness with wait. This is the same problem we’ve seen in class: a race
between the awoken thread re-entering the critical section when returning from wait and a new
thread calling lock to enter.
To see what is happening in this case, let’s assume there is a long queue of people waiting on a
condition variable. When signal is called indicating that a well position is available, the
thread that has been waiting the longest is awoken. This is fair as ensured by the fact that the
condition-variable waiter queue is a fifo. However, if some other thread that has not been
waiting at all is, at this very moment, trying to get into the critical section and it beats the
awoken thread into the critical section, then it may get that thread’s position in the well,
bypassing the awoken thread and every thread on the waiter queue. When this happens the
awoken thread must wait again; and it does this by moving all the way to the back of the waiter
queue. In our case the budger is the thread that just left the well and that just turned around and
tried to get back in again, sometimes succeeding to budge to the front of the line, grabbing the
space it just vacated and forcing that poor sucker it just woke up to go to the back of the line.
The purpose of the uthread_yield() loop after exiting the well is to minimize how often
this situation occurs. You won’t see it happen often. But, it will happen often enough that a few
threads occasionally end up waiting a very long time to get into the well. You might experiment
with calling uthread_yield() more times after leaving the well (or less) and see how this
affects fairness. Resolving this unfairness is tricky and not necessary for this assignment.
Question 2.3: Producer Consumer with Semaphores [10%]
Re-implement Question 1.5 using semaphores by modifying part1/pc.c to use semaphores
for all synchronization. Place your solution in a file named pc_sem.c. Your solution must not
use anything from the uthread_mutex / uthread_cond API.
Bonus 2.4: Endianness Well with Semaphores [20%]
Re-implement Question 2.2 using semaphores as the only synchronization primitive and place
your solution in the file well_sem.c; start from the provided file (or your solution to Question
4).
Notice what happens to the unfairness problem we saw with wait in Question 4 that caused
threads to occasionally lose their place in line and end up waiting a very long time to get into the
well. Explain the difference you see and say why semaphores are different, placing your answer
in the file BONUS.txt.
What to Hand In
Use the handin program.
You will handin parts 1 and two separately.
The assignment directory for Part 1 is ~/cs213/a10part1. It should contain the following
plain-text files.
1. PARTNER.txt containing your partner’s CS login id and nothing else (i.e., the 4- or 5-
digit id in the form a0z1). Your partner should not submit anything.
2. The files: q1.c, q2.c, q3.c, and pc.c. These should stored directly in the a10part1
directory and not in a subdirectory.
The assignment directory for Part 2 is ~/cs213/a10part2. It should contain the following
plain-text files.
1. PARTNER.txt containing your partner’s CS login id and nothing else (i.e., the 4- or 5-
digit id in the form a0z1). Your partner should not submit anything.
2. The files smoke.c, well.c, pc_sem.c and, if you did the bonus question,
well_sem.c and BONUS.txt.
