CS 208: Computer Organization & Architecture

Concurrency, day 1

Goals for today

• Use the pthreads library to create simple threaded programs.
• Understand how simple race conditions can occur.
• Use a pthread mutex variable to make access to shared data atomic, and thereby prevent race conditions.
• Trap SIGINT signals to enable your program to do some final computation before quitting when the user hits Ctrl-C.
• Put it all together for a simple two-thread producer-consumer program.

Previous C labs

In case you want to refer back to them, here are links to the C labs we did a few weeks ago.

• Intro to C: variables, loops, conditionals functions, command-line arguments, file I/O.
• More C: C strings (i.e. null-terminated arrays of char), debugging with lldb, etc.
• Margo Seltzer's nutty treasure hunt lab

A few threading and signal-handling samples

Each of these programs illustrates one simple technique in C. Read the programs, compile them, run them, play with them until you get what they're doing and how.

• pthreads_create.c: this one just creates and launches two threads and lets them run until they're done. (Is the scheduler allocating time fairly to threads A and B? Does either one ever get ahead of the other?)
• pthreads_with_race.c: two really bone-headed threads that go out of their way to create a race condition.
• pthreads_without_race.c: the same silly threads, but this time they use a pthread mutex variable to lock their shared data before messing with it, so as to prevent the race condition.
• unix_signals.c: shows how you can have your program detect a Ctrl-C from the user, and then do something instead of just immediately exiting (which is the Unix default behavior in response to Ctrl-C).
• random_numbers.c: shows how to generate pseudo-random integers in a C program. This isn't a threading example, but you'll need it for the next section.

Putting it all together

Next try writing a simple threaded program of the producer-consumer variety. We'll have two threads with a shared array for storing data. The producer thread will generate data and store it in the array, and the consumer thread will remove data from the shared array and use it for some purpose or other. The producer has to be careful not to try to add new data when the array is already full, and the consumer has to be careful not to try to remove data when the array is empty. Both the "produce" and the "consume" operations require multiple instructions to execute, so there's danger of race conditions.

Here's what your program should do. This is going to be a simple simulation of rolling a pair of six-sided dice a lot of times, and keeping track of how often each sum occurs, producing a statistical report once the user hits Ctrl-C.

• Start with some global variables providing the producer and consumer with a shared array of ints:
  #define BUFFER_CAPACITY 100 int gBuffer[BUFFER_CAPACITY]; int gBufferSize = 0;
  Note the distinction between capacity (how many slots does the shared buffer have?) and size (how many slots are currently in use?)
• Create two threads. Call one the producer and the other the consumer, and name the associated variables and main-functions accordingly.
• The producer should generate random integers between 1 and 6 (each representing one roll of a six-sided die), and stick each one at the end of the shared buffer.
• The consumer should keep an array of counters for each possible sum-of-two-dice and how many times each sum occurs. We would expect, for example, that a sum of 7 would be common, rolls of 2 or 12 would be uncommon, and a roll of 1 or 0 or 13 would be impossible.
• The consumer will remove two dice from the end of the shared buffer, increment the appropriate counter for the sum of the two dice, and repeat.
• When the user hits Ctrl-C, the program should print out the count for each dice sum (with, if you wish, frequency percentages for each sum) and then quit.

Lots of questions here: how do you prevent race conditions? how do you keep the producer from running off the end of the shared buffer? how do you keep the consumer from trying to remove items from an empty buffer? where should the counter variables be so they can be printed when Ctrl-C/SIGINT happens? etc.

Have fun!