CS31 Lab 9: Parallel Game of Life

The main thread should begin by initializing the game board by reading the input file in the same way as the sequential version. The input files format has not changed. Your timing code should not include this step but should include all other parts of the execution.

After initializing the game board, the main thread spawns off worker threads that will simulate multiple rounds of the game, with each thread computing just its portion of cells of the new board each round. Grid cells are allocated to threads using either a row-wise or column-wise partitioning specified by a command line argument. You may assume that you will not be asked to create more threads than there are rows/columns (whichever you’ve been asked to partition by). In other words, you don’t need to worry about a case in which there are threads that have no rows/columns assigned to them.

Your program should use a global variable that will be shared among all threads to count the number of live cells that are processed during each round. That is, each thread must keep a count of the number of live cells it encountered during a round and use that value to update the global count when it has completed its execution of the round. You should NOT count the live cells in the print function like your serial version did! The rationale for this requirement is that it creates a critical section when the threads attempt to write the global values, so you’ll need to use synchronization to protect those writes.

If printing after each round is enabled, you should designate one thread to be the printing thread, and only that thread should do the printing after each round (otherwise the output can be interleaved in crazy ways). It should print both the board and a count of the number of live cells. The output should be identical to that of the serial version.

At the end of the simulation’s execution, the main thread should the elapsed time. You will not be graded on absolute performance, but your code should run faster when run in parallel. As a sanity check, try running a large board instance (e.g., 1500x1500) for many rounds (e.g., 100+). You should see a substantial improvement between running with one thread and a handful of threads (2-4). It’s that sort of relative improvement that we’ll be looking for. Note: for accurate timing, a run with no printing arguments enabled should not include any calls to usleep in the run.

Your simulation should have no valgrind errors other than those suppressed by running valgrind-gol. You only need to run valgrind for output modes 0 and 1, but NOT with the graphics enabled.

Your solution should support using the graphics library. Some details are below and there are comments in the starter code. This is a very small portion of the credit for the lab and isn’t the main focus, so it probably shouldn’t be the first priority.

In main, prior to creating any threads, call init_pthread_animation and get_animation_buffer. The former returns a handle (way of referring to the graphics library) and the latter returns the graphics buffer. Both of these values need to be accessible to all the threads (e.g., as a global variable or passed in the thread’s parameter). The buffer you get back from get_animation_buffer is the buff value you’ll pass into gol_step when the output mode is 2 (OUTPUT_VISI).

In main, after creating the threads, main should call run_animation prior to attempting to join all the threads.

Each thread, when updating the board, should update the graphics buffer with a color for what to draw on the board. This is the same as what you did in the serial version of the lab when you were setting buff[buff_index]. To make things a bit easier for you now, I’ve defined some common colors in colors.h, so you can refer to colors like c3_black, c3_green, etc. The colors.h file also defines an array of eight colors, so you can assign each thread a color by indexing into the colors array using the thread’s id. For example, my code for this portion looks like:

if (buff != NULL) {
    int buff_index = (data->rows - (i + 1)) * data->cols + j;
    if (next_board[i * data->cols + j]) {
        /* Live cells get the color using this thread's ID as the index */
        buff[buff_index] = colors[data->id];
    } else {
        /* Dead cells are blank. */
        buff[buff_index] = c3_black;
    }
}

Somewhere in the code for each worker thread, after you’ve done step 3 to set the colors, every thread needs to call draw_ready(handle) to apply its changes to the board.