Welcome!
To use the personalized features of this site, please log in or register.
If you have forgotten your username or password, we can help.
|
 |
Efficient Detection of Determinacy Races in Cilk Programs
| |
|
Efficient Detection of Determinacy Races in Cilk Programs
M. Feng1 and C. E. Leiserson2
| (1) |
School of Computing, National University of Singapore, 10 Lower Kent Ridge Road, Republic of Singapore 119260 fengmd@nus.edu.sg
, SG |
| (2) |
MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, MA 02139, USA cel@mit.edu, US |
Abstract. A parallel multithreaded program that is ostensibly deterministic may nevertheless behave nondeterministically due to bugs
in the code. These bugs are called determinacy races, and they result when one thread updates a location in shared memory while another thread is concurrently accessing the location.
We have implemented a provably efficient determinacy-race detector for Cilk, an algorithmic multithreaded programming language.
If a Cilk program is run on a given input data set, our debugging tool, which we call the ``Nondeterminator,'' either determines
at least one location in the program that is subject to a determinacy race, or else it certifies that the program is race
free when run on the data set.
The core of the Nondeterminator is an asymptotically efficient serial algorithm (inspired by Tarjan's nearly linear-time
least-common-ancestors algorithm) for detecting determinacy races in series-parallel directed acyclic graphs. For a Cilk program
that runs in T time on one processor and uses v shared-memory locations, the Nondeterminator runs in O(T α(v,v)) time, where α is Tarjan's functional inverse of Ackermann's function, a very slowly growing function which, for all practical purposes,
is bounded above by 4 . The Nondeterminator uses at most a constant factor more space than does the original program. On a variety of Cilk program
benchmarks, the Nondeterminator exhibits a slowdown of less than 12 compared with the serial execution time of the original optimized code, which we contend is an acceptable slowdown for debugging
purposes.
Received December 7, 1997, and in final form October 24, 1998.
Fulltext Preview (Small, Large)
|
|
|
|
|
|