|
Berkeley UPC - Unified Parallel C
|
|
UPC Thrille
UPC Thrille is a tool for "Active Testing" of UPC applications. By observing
shared memory accesses and synchronization behavior of a program, Thrille can
detect potential concurrency bugs in UPC programs. Thrille will then re-execute
the program while actively controlling the schedule of threads and try to
reproduce the potential bugs and confirm their existence. In this current
release, a data race detection and reproduction tool is included.
Latest News
- May 14 2012 - New public release of Thrille to match Berkeley UPC 2.14.2 is here!
- Oct 25 2011 - Download the minor update for compatibility with Berkeley UPC 2.13.6.
- Oct 21 2011 - New public release of Thrille is here!
- Oct 19 2010 - Initial release of Thrille is here!
Downloading and Installing UPC Thrille
- Download and unpack Berkeley UPC on your system. Instructions for downloading Berkeley UPC can be found here.
- Download and unpack Thrille. The default location for Thrille expected by Berkeley UPC is [path to berkeley_upc-x.y.z]/thrille. You can either create a symlink called 'thrille' to the directory you unpacked Thrille (thrille-x.y.z), or specify the path during configuration (see below).
- Configure Berkeley UPC with Thrille support. Create a build directory (e.g. ~/upc/build), and run configure with option "--enable-thrille". Unless you added a symlink called 'thrille' in 'berkeley_upc-x.y.z' (or moved the thrille package there), you must also add the option "--with-thrille=[path to thrille-x.y.z]". You should specify the absolute path when using the "--with-thrille" option.
- ~/upc/build$ [path to berkeley_upc-x.y.z]/configure --enable-thrille --with-thrille=$HOME/upc/thrille-0.9.19 [additional options]
- Build the Berkeley UPC runtime. In your build directory, run "make" and optionally "make install". If you have problems building the Berkeley UPC runtime, consult the INSTALL manual inside the BUPC package.
- Test if your installation is correct. The Thrille package comes with some test programs. You can try the simple test program in thrille-x.y.z/tests/hello. Note: the program will have a race only when run with 4 or more threads.
- thrille-0.9.19/tests/hello$ make (you may need to edit Makefile to change compiler flags, conduit etc.)
- thrille-0.9.19/tests/hello$ upcrun -np 4 hello-racer (should report a potential data race and produce a file named upct.race.1)
- thrille-0.9.19/tests/hello$ UPCT_RACE_ID=1 upcrun -np 4 hello-tester (should reproduce the race with a message "REAL RACE CONFIRMED")
- thrille-0.9.19/tests/hello$ UPCT_RACE_ID=1 UPCR_RACE_RESOLVE_DIR=1 upcrun -np 4 hello-tester (should reproduce the race in the opposite order)
Running UPC Thrille
- Compile your UPC program with Thrille enabled. You must specify a mode by adding "-thrille=[mode] (default:empty)" to the upcc compiler options if you want Thrille enabled in your program runs. Currently, the supported modes are {empty, racer, tester}.
- Run your UPC program with Thrille race detection. After you compile your program with "-thrille=racer", run your program normally with upcrun. All potential races will be reported in separate upct.race.<num> files. If run on a distributed system, these files may also be dispersed among nodes.
- Run your UPC program with Thrille race reproduction. After you compile your program with "-thrille=tester", select the race you would like to reproduce using the environment variable "UPCT_RACE_ID=<num>", and run your program normally using upcrun. The syntax for setting up environment variables depends on your shell. To change the order of resolving races, define the environment variable UPCT_RACE_RESOLVE_DIR=1. The default order (UPCT_RACE_RESOLVE_DIR=0) is to let the thread paused at the first statement of the race pair start first after the race is detected.
Version history
- 0.9.19 - Added compiler instrumentation for shared memory access using local pointers
- 0.9.18 - Upgraded tester for scalability
- 0.9.17b - Minor patch in upcr_lock.h to match newest Berkeley UPC runtime
- 0.9.17 - Bug fixes for racer and tester
- 0.9.16 - Reduced unnecessary memory allocations in racer
- 0.9.15 - Reduced unnecessary communication of probabilities in tester
- 0.9.14 - Reimplemented map for enhanced performance (needs confirmation)
- 0.9.13 - Changed pull-based communicated to push-based
- 0.9.12 - Implementation of exponential backoff on probability of considering memory access for data races
- 0.9.11 - Implementation of non-blocking transfers between threads at barrier boundary (marginal improvement in scalability)
- 0.9.10 - Reimplementation of skiplists for added efficiency (insignificant improvement)
- 0.9.9 - Added Communication/Computation stats options (programs must define certain variables and print them on their own)
- 0.9.8a - Testing phase uses local probability to avoid too much communication
- 0.9.8 - Removes all dynamic allocation of memory scattered in the code and uses recycled memory pools.
The only malloc()s are to increase the size of a pool
- 0.9.7 - Turns off stats collection by default (compile with -DTHRILLE_STATS to enable)
- 0.9.6 - Updated mode_tester with exponential backoff
- 0.9.5 - Fixed memory leaks and allocation issues
Feedback
Please send all bug reports and comments to
This page last modified on Saturday, 24-Sep-2016 20:41:40 PDT