Exercise 9: Concurrency Code Review

In this exercise, you read four short programs that use threads and explain what they do: whether they give the right answer, whether they finish, and whether they use memory safely. The programs are complete and ready to run. The graded questions do not ask you to write code. Write every answer in questions.txt.

The questions ask you about:

• getting answers back from threads and freeing that memory;
• read-modify-write race conditions and mutexes;
• deadlock, and locking in the same order everywhere; and
• tracking down a threading bug by running a program more than once and looking at it in gdb.

Thread Operation Reminder

Examples 1, 2, and 4 use the pthread functions from lecture:

• pthread_create starts a new thread running a function, and hands that function one void* argument.
• pthread_join waits for one thread to finish, and can pick up the void* that the thread returned.
• pthread_mutex_init sets up a mutex before any thread uses it, and pthread_mutex_destroy cleans it up after every thread has finished.
• pthread_mutex_lock waits until this thread has the lock. pthread_mutex_unlock gives the lock back once the shared data is done being changed.

Threads in one process each get their own registers and stack, but they share the heap, the globals, and any stack variable whose address they are given. A mutex only helps if every thread locks the same mutex before touching that shared data.

What to Expect

The four programs do not all behave the same way. Some do what they are supposed to do. Others have a bug, get stuck, or print the answer you expected while still having a problem.

Your job is to figure out which one is which. The questions walk you through it: find the data that threads share, find where memory is created and freed, mark where locks are taken and given back, and think about what order the threads can run in. Do not assume every program needs another mutex, and remember that one good run does not mean the program is always right.

Files

• questions.txt contains every response field. You complete this.
• example1.cc splits one sum among several pthread threads and adds up their answers.
• example2.cc uses two pthread threads to book seats for one show.
• example3.cc uses C++ threads and mutexes to swap songs between two playlists.
• example4.cc hands five pthread threads their jobs, and is the one you track down in gdb.
• Makefile builds all four programs.

Run each program the way questions.txt tells you to, then answer its questions in order. Each part asks one short question. Say enough that we can tell the difference between something that is always true and something that happened only on the run you tried.

After you finish the four programs, answer the reflection: what is hard about threads, when they are worth using, and when they are not.

The BONUS section suggests optional changes you can try in the source files. These experiments are ungraded. Restore the source files before creating your submission tag.

Collaboration is encouraged, and there are no limits on how much you can work with other people on these questions. Read the programs with other students, compare what you each saw when you ran them, and ask the course staff when you get stuck. Write your final answers in your own words and fill in the collaboration section at the end of the file.

Submit your work by creating an ex9-submit tag in your exercise repository before the deadline. Submit exactly one student-edited file at the path below:

• ex9/questions.txt