Copy the week 13 files:

$ cd cs31/inclass
$ cp -r ~mauskop/public/cs31/week13/ .

mutex.c and barrier.c demonstrate how to use a mutex and how to use a barrier, respectively.

• You can see specs for all the CPUs on a lab machine (and see how many cpus there are) by looking at the cpuinfo file in /proc (cat it out or open in an editor):

  # pipe cat's output through less (space to page fwd, q to quit)
  cat /proc/cpuinfo | less
  

• CS lab machine specs contains information about different machines in our lab. If you look at the Machine Table link you can see the number of cores listed for each machine. You can ssh into a machine with 8 (or 12) cpus to run a multithread program over more processors.

top is a Unix utility that lists information about processes and threads and how they are using resources like memory and CPU. If you run top with no command line options, then it displays per-process statistics. If you run top with -H, top will display statistics for individual threads:

top -H

Debugging threaded programs can be tricky because there are multiple streams of execution. In general, try to debug with as few threads as possible, and if you use printfs, print out a thread id and call fflush after. You can also put printf's in conditional statements to only have one of the threads print out information (or only some of the threads, or only some of the information, ...).

gdb and pthreads

We are not going to look at this together in lab, but if you want to try using gdb to debug your pthread code, here is some general information about it and an example you can try out: Debugging pthreads programs with gdb.

More detailed information about gdb and pthreads can be found here: gdb and pthreads