CSE 160 Homework Assignment #1
Multithreaded plotting server with the Game of Life
TO BE DONE IN TEAMS OF TWO
(10 points)

Due: Tuesday 10/14 at 9PM


Changelog

Date Description
06-Oct-08 Original posting
13-Oct-08 How to test your code


Introduction

In this assignment you'll employ multithreading to handle graphical display in single processor implementation of Conway's game of Life. You'll reuse this code in the next assignment, when you parallelize the Game calculation.

Conway's Game of Life

Conway's game of life is a cellular automaton, in which cells living on a 2-dimensional world live, are born, and die over successive generations. The world is defined as a binary-valued array, and each generation evolves according to the following rules, where Worldt[i,j] is point i,j in the current generation (t), and Worldt+1[i,j] is point i,j in the next generation.

  for t in 0:T-1
      forall (i,j) in 1:N × 1:N
          nNeigh = number of neighbors of Worldt[i,j]
          if Worldt[i,j] AND (nNeigh == 2 or nNeigh ==3) then
            Worldt+1[i,j] = LIVE
          else
            Worldt+1[i,j] = (nNeigh == 3)
          end if
      end forall
    end for

Serial Code

We are providing you with a working serial program that implements Conway's Game of Life. The provided code creates a random world, distributing cells uniformly according to a specified probability. It then runs the game of life for a given number of generations, sending output to the gnuplot plotting program. You'll modify the code to run the game of life and the plotter within two separate threads using PThreads. Shared memory will enable the threads to communicate in a producer-consumer relationship.

To run the program, you will need the gnuplot plotting program to be installed on your computer. You can download the software from http://www.gnuplot.info (There is also a somewhat older documentation, see Brief Manual and Tutorial

The code we are providing is found here. The Makefile includes an "arch" file that defines appropriate command line flags for the compiler.

The program may be run from the command prompt as follows:

./life [-nx <int>] [-ny <int>] [-nt <int>] [-s <int>] [-p <float >]

With the arguments interpreted as follows:

-nx <integer> Number of mesh points in the x dimension
-ny <integer> Number of mesh points in the y dimension
-nt <integer> Number of iteration timesteps
-s  <integer>  Random seed
-p  <float>     Distribution probability

The default parameters are described in life.c.

And, the command line

        ./life -nx 100 -ny 100 -nt 200

will initialize a 100 by 100 world and run the simulation for 200 generations.

NOTE: If a gnuplot window does not appear on your screen, then your SSH display settings are not set correctly. If you are using a Linux based machine and are connecting to a Linux machine using SSH, use the -X option:

% ssh -X yourlogin@machine.ucsd.edu

If you are using a Windows based machine, and are using a 'secure shell client' AND 'exceed' (or xwin32, or cygwin) to log into Linux machine, you must ensure that 'X11 tunneling' is set. [If you have problems with this, first read our webboard on this issue. If you still have the problem, send email to Pietro.]

The Assignment

In this assignment, you'll make 2 modifications to the provided code: handle wrap around boundary conditions and support functional parallelism to handle display.

1. Wrap around

When cells move to the edge of the world, they do not have neighbors on the wall itself. This will cause some cells to die out. To eliminate this artifact, modify the code to employ periodic boundary conditions, where neighbors are defined to wrap around to the opposite edge (what about corners?). This will cause a cells to migrate through an edge onto the opposite side, and achieve the effect of an infinite world.

2. Functional Parallelism

The game of life generates intriguing displays as well as insight into the population dynamics. In this part you'll modify the provided serial life simulator to run as two PThreads. One thread (the plotter thread) should handle the display (via gnuplot) while the other thread (the main thread) should perform the cell updates. The two activities may take place concurrently. To synchronize the execution of the two threads, mutexes or the semaphores implementation provided should be used. Data should be transferred between the processes via shared-memory and a gnuplot display mesh plot must appear for each iteration.

How to test your code [10/13/08]

To test your code, run with a problem that has a known solution. The literature is full of problems with known solutions. The simplest problems to test have the static patterns that don’t change. You can find some examples on the Wikipedia page for Conway’s Game of Life Others include "blinkers" and gliders, again, see the Wikipedia page, or search the internet for other test problems. To help you in your testing, a new version of life.c has been posted, which is called life_10-13.c. A new command line option -g has been added, which allows you to select a game number, and one game (for the value of g=1) has been added to the code. Additional code has been added to allow you to "single step" through the game, one iteration at a time. This is handy for catching moving patterns.

Things you should turn in

Document your work in a well-written report which discusses your findings carefully. Your report should present a clear evaluation of the design of your code, including bottlenecks of the implementation, and describe any special coding or tuned parameters. Provide code listings for files you wrote, or that you modified based on versions we gave to you. There is no need to provide listings of code we provided, that you did not modify.

Your report should cite any written works or software as appropriate in the text of the report. Citations should include any software you used that was written by someone else, or that was written by you for purposes other than this class.

Provide hard copy by the due date. Also transmit the report electronically along with your code and your plots report. Be sure and delete all .o files and executables before creating the tar file. Transmit a single archive file, e.g. .zip, .tgz, containing your writeup, and source code, plus any output files. Email the archive file as an attachment to the following address:

pcicotti +160_a1 @ ucsd.
edu
Be sure to put the string cse160:A1 in the subject line and to use the email address above; not doing so may result in a penalty.

The name of your tar file should start with your login ID, e.g. baden.tgz. Your archive file should create a directory with the name of your login ID. The directory should contain two subdirectories

src:     All source code including your makefile, so we can build the software.
report: Your report including any separate image files, screen shots, or other output.

At the top level of your directory there should be an ASCII file called README.txt, that lists all the parts of your electronic submission. If you like, include an html file called index.html at the top level. From there you can then link to a README file as well as the src and report directories.



Sources of information about Conway's game of Life

  • http://bloemenbuurt.bitstorm.org/gameoflife/
  • http://bloemenbuurt.bitstorm.org/gameoflife/code/
  • http://www.radicaleye.com/lifepage/
  • http://ddi.cs.uni-potsdam.de/HyFISCH/Produzieren/lis_projekt/proj_gamelife/ConwayScientificAmerican.htm
  • http://www.ibiblio.org/lifepatterns


  • Copyright © 2008 Scott B. Baden

    Maintained by baden @ ucsd.
    edu   [Mon Oct 13 16:03:53 PDT 2008]