CECS Home | ANU Home | Search ANU
The Australian National University
ANU College of Engineering and Computer Science
School of Computer Science
Printer Friendly Version of this Document

UniSAFE

COMP8320 Laboratory 05 - week 5, 2011

Catchup and Thread Analysis Tools


This session will provide some experience on an aspect of advanced OpenMP and develop some experience using tools to detect race conditions, one of the most perplexing phenomenae of parallel programming.

From wallaman, copy the files for the session into your home directory:

    cp -pr /dept/dcs/comp8320/public/lab05/ .

Catchup!

If you have not completed Lab 04 (or got stuck on some part of it) now's a good chance to do this!

Detecting Race Conditions in the Thread Analyzer Tool

  1. Inspect the code in race.c; you will notice that it corresponds to an example involving the inv() function used in Lecture 5. Compile the program using:
      cc -xopenmp -fast -o race race.c
    and set the number of threads to a largish number, say:
      export OMP_NUM_THREADS=24
    Run the program race several times. What do you observe?

  2. Now compile the program using:
      cc -g -xinstrument=datarace -xvpara -xopenmp -fast -o race race.c
    You will probably find the program, run on its own, no longer displays a race. Now run the program with collection of race statistics and invoke the thread analyzer.
      mkdir /tmp/$USER; rm -rf /tmp/$USER/*
      collect -r on -d /tmp/$USER ./race
      analyzer /tmp/$USER/tha.1.er &
    First, select the Races tab. What do you see? Then, select the Source tab to observe the number of race accesses detected. Also, observe the annotations around the OpenMP loops in the main program.

  3. To see how this works, select the Dissembly tab. Inspect the code for inv() (top of the listing). The clr instruction corresponds to first = 0; the std instruction corresponds to a = 0. The fdivd instruction corresponds to computing 1.0 / a. You will observe that reads and writes to shared data are instrumented with corresponding calls to the thread analyser library. The number of races in detected from each call is recorded.

  4. The above exercises can be repeated using the text-friendly utility:
      er_print /tmp/$USER/tha.1.er
    with the sub-commands:
      races
      rdetail all
      lines
      source race.c
      disasm race.c
      quit

  5. Race mysteries. The compiler did not re-order the stores to first and a in inv(). So how is a race possible? A second mystery is that uncommenting the barrier before the call to inv() seems to removes the race. Why?

Last modified: 18/08/2011, 13:17

Copyright | Disclaimer | Privacy | Contact ANU