What Are Race Conditions? Some Issues and Formalization ROBERT
H. B. NETZER
University
of Wisconsin
In
shared-memory
when
to
a race
to programs
to nondeterministic examines
We
show
data
capture
the
accurate
notions
implicitly
locating
feasible
races
has
can
incapable argue
by two
variations
intuitive
notions
assumed
located
of implementing
mutual
than
debugging
data
races
contrast,
general
data
programs
Categories
and
debugging
atds;
concurrent
programming
concurrency, General
Key
parallel
research
of Naval Research
Grant, address:
Dayton
and
Street,
a formal
of race
debugging
for
This
result
exhaustive
requires
only
debugged races
require
[Software
D.2.5
races
methods.
We also show
D.4. 1
the
apparent
races capture
races,
and less that
which
of synchronization
important detection
race
implications and
are
complex
Language
Programs
easily
are we
harder containing
identifiable
debugging
races.
In
techniques.
Testing
and Debugging–
Constructs
Systems]:
that since
is inherently
detection)
certain
[Operating
general
their
apparent
Engineering]:
Languages]:
paper
exploring
and
types
race
more
However, This
The complexity of dynamically used by the program, Apparent
has
partial
other
feasible
only
weak
by locating
races).
recognized. and
one
and the
exist:
practice. of synchronization only
races)
model
race detection that
as to precisely considered:
data
been
often
to behave
and
Process
Features—
Management—
synchronization
Phrases:
Critical
sections,
data
races,
debugging,
nondeterminacy,
conditions
was supported
Authors’
for
yet
program
implicitly general
result are
Languages
race
Research
type
the
we call
not
using
implying
type
structures;
Words
programs,
(which
conditions
conditions
literature
been
we call
have
requires
general
exclusion,
sections
dynamic
exclusion.
(which
have
be detected in
[Programming
Design,
in the
races
desired
efficiently
Descriptors:
D.3, 3
mutual
Terms:
Additional
This
Subject
agreement
races
problem,
be efficiently
containing
can cause
(which
of each
race Race
presence
notions
data
by most
races
races
can therefore
little
different
characterizing
is an NP-hard
debugging
been
and
synchronization, synchronized.
their
critical
races
be exhaustively
that
since
containing
approximations to feasible races, can locating apparent races depends on the races
explicit
properly
to be deterministic
general
that
use
not
Two
intended
differences
properties. races
there condition.
between
these
are
of bugs,
programs
differences
that
memory
Unfortunately,
constitutes
pertaining the
programs
shared
to be manifestations
unexpectedly, what
P. MILLER
— Madison
parallel
accesses
considered
and BARTON
grant
in part
Computer
Madison,
by National
Science
NOO014-89.J-lZZZ, Sciences
WI
53706;
and
Department, e-mail:
Foundation
a Digital
grant
CCR-8815928,
Equipment
University
R. H. B. Netzer,
Corporation
of Wisconsin-Madison,
[email protected];
Office External 1210
W.
B. P. Miller,
[email protected], Permission not made of the
to copy without or distributed
publication
Association specific
its
for Computing
date
of this
commercial
appear,
Machinery.
and
material
advantage, notice
is given
To copy otherwise,
is granted the ACM that
provided copyright
copying
or to repubhsh,
that notice
the copies
is by permwsion requires
Letters
1057-4514/92/0300-0074 on Programming
Languages
Vol.
1, No. 1, March
of the
a fee and/or
$01.50 and Systems,
are
and the title
permission.
@ 1992 ACM ACM
and
fee all or part
for direct
1992, Pages 74-88
What Are Race Conditions?
.
75
1. INTRODUCTION In shared-memory properly
parallel
synchronized,
programs,
if accesses
time-dependent
to shared
failuresl
called
memory
race
are not
conditions
can
result. without
Race conditions occur when different processes access shared data explicit synchronization. Because races can cause the program to
behave
in ways
unexpected
by the programmer,
detecting
tant aspect of debugging. However, in the literature, agreement as to precisely what constitutes a race different notions have been used, but the distinction been previously several terms
recognized. have been
access anomaly
[6–8,
[131, harmful
dynamic
race [1,4, 5, 11 , 16, 20, 22],
12, 18], data
access [241, race condition
paper explores the nature hidden issues regarding
race detection.
is an impor-
Because no consistent terminology has appeared, used with different intended meanings, such as
shared-memory
[2, 9, 171. This some previously
them
there seems to be little condition. Indeed, two between them has not
We present
critical
race
[10, 26], or just
race
of race conditions the accuracy and
the following
and uncovers complexity of
results.
(1) Two fundamentally different types of races, that capture different kinds of bugs in different classes of parallel programs, can occur. General races cause nondeterministic execution and are failures in programs intended to be deterministic. Data races cause nonatomic execution of critical sections and are failures in (nondeterministic) programs that access and update
shared
(2) To represent terize
the
(which
data
in critical
the sources intuitive
we
call
a
sections.
2
of race conditions
notion
of a race
feasible
race).
In
precisely,
we
wish
we formally
to
contrast,
detect
we
show
for
characdebugging
that
there
is a
simpler to detect but less accurate notion of a race that most previously proposed race detection methods locate (which we call an apparent race). Feasible
races
are based
on the possible
behavior
of the program;
appar-
ent races, which are approximations to feasible races, are based on only the behavior of the program’s explicit synchronization (and not the semantics (3) Exactly problem.
of the program’s locating the This result
to locate,
must
computation).
feasible implies
be detected
general races or data races is an NP-hard that the apparent races, which are simpler for debugging
in practice.
(4) Apparent races can be exhaustively located efficiently only for programs that use synchronization incapable of implementing mutual exclusion (such as fork/join or Post/Wait synchronization without Clear operations); detection is NP-hard for more powerful types of synchronization (such as semaphores).
1 To be consistent program’s
external
(although 2 There
with
the
behavior
we use the term is some controversy
and general
race,
atomicity ACM
fault
tolerant
differs
from
research its
community
specification,
and
[25],
a failure
a fault
is its
occurs
when
algorithmic
a
cause
bug). over
terminology
race
and determinacy
Letters
on Programming
that
is the
most
race have Languages
descriptive.
also been
and Systems,
In place
of data
race
suggested. Vol.
1, No. 1, March
1992.
76
R. H. Netzer and B. P. Miller
.
(5) Debugging inherently
race more
conditions in programs intended difficult than in nondeterministic
to be deterministic is programs. Races that
cause nonatomic execution of critical sections (data properties of the execution and can be detected directly trace. In contrast, races that cause nondeterministic
races) are “local” from an execution execution (general
races)
whose
detection
requires
alternative
event
orderings
are
“global”
analyzing
the
possibly
exhibited
These
results
dynamic
properties
entire
of the
execution
program
to compute
by the program.
provide
an understanding
race detection.
acterizations of the program bugs. For
Previous
different example,
work
types race
of race
conditions
has not provided
important
unambiguous
for char-
of race conditions or related races conditions have only been defined
to as
occurring when two shared-memory references “can potentially execute concurrently” [6] or have no “guaranteed run-time ordering” [101. Our work is novel since we explicitly characterize two different types of race conditions using
a formal
general
races
different
types
Using
a model
model
and
and data
explore
races
of program has
the
complexity of dynamic have implications for
their
properties.
is necessary bugs
and
advantage
The
because
require that
distinction
between
are manifestations
different
issues
race detection then debugging: accurate
they
detection
regarding
the
of
techniques. accuracy
and
become clear. The accuracy issues race detection means that races
that are direct manifestations of program bugs are pinpointed, while less accurate detection can report spurious races that mislead a programmer. The complexity issues show which types of races allow exact and efficient detection and which can be only approximately located. Our results show that locating is computationally intractable. methods races.
take
However,
effective
an easier
approach
we argue
debugging
exactly Indeed,
that
requires
and
apparent more
the desired previously locate
only
races (the feasible races) proposed race detection a subset
races can often
sophisticated
of the
be spurious,
techniques.
Race
apparent and that conditions
can be debugged by attempting to determine which of these located (apparent) races are of interest for debugging (i.e., are feasible). Our results show that there is also a fundamental disparity between debugging race conditions in deterministic and nondeterministic programs. Nondeterministic programs that use critical sections can be safely debugged (to find data races) because we can easily determine if an execution is data-race free; when data races occur, the feasible races can be approximately located. However, debugging programs ently harder.
intended to be deterministic (to find general races) We can be confident that execution was deterministic
exhaustive race detection efficient only for programs mutual exclusion).
is inheronly if
shows an absence of general races (and this using synchronization incapable of implementing
2. EXAMPLES Explicit
synchronization
to coordinate ACM
Letters
is often
accesses to shared
on Programming
Languages
added data.
to shared-memory Without
and Systems,
Vol.
proper
parallel
programs
coordination,
different
1, No. 1, March
1992,
is
What Are Race Conditions? types of race conditions we present an example them
in terms
can result. To motivate of each. In subsequent
of a formal
model
One purpose of adding programs is to implement to execute state initial the
as if they
were
their
synchronization sections, which
atomic.
Atomic
77
these different types of races, sections we will characterize
and investigate
explicit critical
.
properties.
to shared-memory parallel are blocks of code intended
execution
means
that
the
final
of variables read and written in the section depends only upon their state at the start of the section and upon the operations performed by code
(and
conditions
not
state
operations
that
atomic
are read and modified concurrently executing typically
been called
performed execution
This
another
process). if shared
by the critical section are not modified section of code [3]. A violation of these a data
program
data race. program for which
processes
deposits
and withdrawals
version
of the
program.
Bernstein’s variables
that
by any other conditions has
race [1, 4, 5, 11, 16, 17, 20, 221 or access anomaly
[6-8, 181. We prefer the term Figure 1 shows an example failure.
by
is guaranteed
commands
for a given Since
the
bank
a data
from
account.
variables
bank
race is considered tellers
Figure
balance
and
that
la shows interest
a
make
a correct
are shared,
operations that manipulate them are enclosed in critical sections. Because critical sections can never execute concurrently, this version will exhibit no data races. Figure lb shows an erroneous version that can exhibit data races; the P and V operations that enforced mutual exclusion are missing. The deposit and withdraw code can therefore execute concurrently, causing their individual statements to effectiwdy interleave, possibly violating the atomicity of one of the intended considered
failures
critical
because
sections.
the
code execute atomically, without Even though programs like
intent
The data
was that
interference the one in
the
races in this deposit
program
are
and withdrawal
from other processes. Figure 1 may contain
critical
sections, they are often intended to be nondeterministic (e.g., the order of deposits and withdrawals may occur unpredictably, depending on how fast the tellers type). However, other classes of programs are intended to be completely deterministic, such programs. In these forcing input)
and a different type of race condition pertains programs, synchronization provides determinism
all accesses to the same shared in a specific
always
produce
among
the processes
the
order.
For
a given
same result,
resource input,
regardless
in the program
to always
execute
all executions
to by
(on a given
of such programs
of any random
timing
(e. g., due to unpredictable
variations
interrupts,
or
other programs that may be executing on the same processors). Nondeterminism is generally introduced when the order of two accesses to the same resource is not enforced by the program’s synchronization. The existence of two such unordered accesses has been called a race condition [9, 10, 261, access anomaly [121, critical race [131, or harmful shared-memory access [241. For a more consistent terminology, we propose the term general race, since such a race is more general than a data race. As an example of programs for which general races are manifestations of bugs, consider parallel programs that are constructed from sequential programs by parallelizing loops. The sequential version of a program behaves ACM
Letters
on Programming
Langnages
and Systems,
Vol.
1, No. 1, March
1992.
78
R. H. Netzer and B. P. Miller
.
Process 1
/*
DEPOSIT
amount P(nmtex)
Process 2
*/
=
/*
read_amounto ;
balance
+ amount;
= interest
V(mutex)
=
P(mutex)
= balance
interest
WITHDRAW
amount
;
if
*/
read_amounto
(balance
+ rate*balance;
< amount)
printf(’TNSF”)
;
else
;
; ;
{ balance
= balance
interest
-
= interest
amount; +
rate*balance;
1 V(mutex); (a): no-data-race
version
Process 1
/h
DEpQS~~
amount
=
k/
/*
read_amounto
P(mutex)
;
balance
=
interest
Process 2
;
~~~HD~~
amount if
balance =
interest
+
,/ read_amounto
(balance
amount; +
=
Races
natural
Since
perform
way
FDIFF
a and
to characterize
precisely
b. For
a race
Ca@UreS
general
the
races,
(a, b) is to consider
Set
we
FsA ME is inadequate since, by definition, a general race exists between two accesses only if they execute in an order different than in P (and therefore the shared-data dependence between them is also different). In contrast, data races could be reasonably viewed as occurring over either F~IFF or FsA ME. Definition
A feasible
4.3.
over F~IFF exists. A feasible data A
feasible
allowed
a race,
race
general
race (a, b) exists locates
and thus
race (a, b) exists iff a data
precisely represents
those the
ACM Letters on Programming
race
(a, b) over
portions
intuitive
iff a general
of the
notion
F~lpR
race (a, b) exists.
execution
that
of a race illustrated
Languages and Systems, Vol. 1, No, 1, March 1992.
84
.
R. H. Netzerand
B. P. Miller
in Section 2. However, checking for the presence of a feasible general race or data race (a, b) requires determining whether a feasible program execution in which b ~ a (or a ~ b, or a % b) is a member of FDI~~. We have proven that
deciding
these
synchronization NP-hard
[19,
the
conditions
race
suggests next.
membership
the 21].
that,
Indeed,
problems
program
It
uses)
is therefore exhibited
in
practice,
that
proposed
race
feasible
problem
an execution settle
(no matter
locating
an intractable by
we must
previously
is NP-hard
and
of the
for
what
type
races
is also
to locate program.
detection
methods
precisely
This
an approximation,
of
result
discussed
compute
such
an
approximation. 4.3 In
Apparent practice,
require could
locating
the
analyzing have
Previously explicit
Races
the
allowed proposed
intuitive
notion
program’s
of a race
semantics
to
b to precede
a (or
methods
a simpler
synchronization
take
performed
b to execute
by the
that
the
program’s
explicit
execution.
An
4.4. F~Y~c
apparent
Because races
may
shared
An apparent exists.
data
not all
race (a, b) exists
program
be spurious.
variables
general
executions Spurious
are used (directly
and For
iff a data in
races
example,
with
a),
only
the
a and
might orderings,
b
(a, b) exists race
iff
occur
or indirectly)
allow.
Be-
these
races
a general
race
(a, b) over
F~ YNC are feasible, can
would
execution
analyze
synchronization
race
the
(or in some other order) if doing so. We can characterF~ ~Nc, which is based only
cause the program may not be able to exhibit such capture a less accurate notion than feasible races. Definition (a, b) over
race)
if
concurrently
approach
are said to have potentially executed concurrently no explicit synchronization prevented them from ize the races detected by this approach by using on orderings
(a feasible
determine
whenever
in conditional
F~ ~~c exists. some apparent values
of
expressions
the
or
shared-array subscripts [20, 221. In such cases, the existence of one event may depend on another event occurring first. For example, consider one process in P that adds data to a shared buffer and then sets a flag BufEmpty to false, and another process that first tests Bufi!?mpty and then removes data from the buffer only if BufEmpty equals false. Such an execution has two apparent general races, between the accesses to BufEmpty and between the accesses to the buffer. However, the race involving feasible execution exists in which data is removed
the buffer is spurious— no from the buffer before the
buffer is filled (since Bufl?mpty is first tested before data is removed). If the operations on the shared buffer were instead complex and involved many shared-memory references, a large number of spurious races could be re ported. Spurious races pose a problem since they are not direct manifestations of any program bug [20, 22]. The programmer can be overwhelmed with large amounts of misleading information, irrelevant for debugging, that masks the location of actual failures. Nonetheless, apparent race detection provides valuable least one feasible ACM
Letters
information, race exists
on Programming
since apparent races exist if and only if at somewhere in the execution [22]. Moreover, we
Languages
and Systems,
Vol.
1, No. 1, March
1992.
What Are Race Conditions? have
proven
apparent
results
races,
showing
and
conservatively
how
determine
for debugging
[20-22].
We have
also proven
how to reason a postmortem
which that,
about race
apparent
for
races
program
ciently
without
detected
Clear
operations);
in executions
are not of interest implement critical
ent
is therefore
data
races
apparent
general
However,
as we discuss
Debugging
always
race detection
important
next,
aspect
or inconsistent
dats
an
recorded
before
events
To locate
portions
might
events
determination executions
(or absence)
of only
to note
complexity
of used.
data races to detect
determining they
general
whether
races
outcome
races
containing
data
a certain
subset
for
races,
race that to fail deposited
it suffices apparent
Locating
results in a because of than with-
to determine
races cause
trace events
meaningless
we now argue
only
of the
race.
exhibit
it is necessary general
(which
of the contain
of any
may
However,
harder
data
a programmer
portions
of the trace
program
of
by incorrect
example,
on
portions
by a race,
portions
are unaffected
only
by the the
are race free. for
the
debugging
[5, 20]. For
These
unaffected
than
be effi-
of synchronization
lb, for example, a data subsequent withdrawals more money has been
is inherently
nondeterminism)
contrast,
while
focus
because
of the execution
For
involves
to be unaffected
important
can thus
Detection
by a race
trace
behavior after a race. In Figure negative balance might cause insufficient funds when in fact
fail).
determining [19]. Member-
It is important
for debugging
races,
any races occurred.
is
In
in the sense that
produced
execution
are guaranteed
this
of interest
synchronization
races
[23].
on the type
it is sufficient
of debugging
are race-free
browsing
drawn.
to
programs since weaker synchroExhaustively locating all appar-
NP-hard.
depends
with Race Condition
the execution
such
and
using
apparent
programs
for such sections.
only a certain subset of apparent requires exhaustive detection.
that
are feasible
mutual exclusion, races is NP-hard
all
of such
that data races nization cannot
An
of
be extended
F~ ~~c is efficiently computable only for weaker synchronization of implementing mutual exclusion (such as Post/Wait style syn-
chronization
4.4
85
feasibility
can
executions
powerful enough to implement two-process membership in F~ YNC and locating apparent ship in incapable
the potential
detector
.
that
(which
introduce
critical
to detect races.
if
making
sections
to
the presence In
contrast,
to
debug executions containing general races, it is necessary to perform exhaustive apparent general race detection. Data races can be viewed as a local property of the execution which can be determined directly from the actual program execution, P. Because an intended
critical
section
can
execute
conflicting events are concurrently detected directly from P. Definition exists. 6 6A
data
race
4.5.
An
actual
in p ~xi~t~ iff a data ACM
Letters
data
nonatomically executing,
an
race (a, b) exists
race exists
on Programming
over
{P},
Languages
only
when
actual
data
iff a data
the set containing and Systems,
Vol.
other race
datacan be
race (a, b) in
P
OnlY p. 1, No. 1, March
1992.
86
R. H. Netzer and B. P. Miller
.
An actual data race indicates the possibility that the atomicity of a critical section may have actually failed. In contrast, general races are a global property of the program which can be determined only by computing alternative event orderings. In general, determining if two events could have occurred entire
in a different execution;
order
there
requires
analyzing
is no notion
the synchronization
of an actual
general
race.
over the Thus,
unlike
general races, actual data races can be easily located if the temporal ing, ~, is known; computing alternative orderings is unnecessary. This races
difference that
are
has important not
actual
implications
data
races
for
cannot
debugging.
produce
order-
Apparent
inconsistent
data
data (be-
cause no critical sections fail), but any apparent general race indicates such a possibility (because two shared-memory accesses could have executed in the incorrect order). The absence of an actual data race therefore indicates that all intended critical sections in P executed atomically, and the location of an actual race pinpoints places in the execution where inconsistent data should be expected. located,
Even
though
we can efficiently
Thus, we inconsistent
not
all
apparent
determine
can easily determine data which cannot
data
whether
races
any actual
can
be efficiently
data races occurred.
whether the observed execution be relied upon for debugging.
because there is no notion of an actual general race, we must locate all apparent general races to make this determination. apparent occurred These data
races
exist
can
in the expected results suggest
races by locating
can only apparent
apply
we
be
all actual
can
that
all
to programs
be efficiently
located.
shared-memory
data
containing As
powerful
types
of synchronization
(such
races. general
discussed
apparent general race detection is efficient only synchronization incapable of implementing mutual more
exhaustively Only if no references
order was possible). debug programs containing
and some apparent
such an approach
races
sure
order (because no other that we can efficiently
contains However,
above,
However, races
exhaustive
for programs that exclusion. However,
as semaphores),
we if all use
for
conservative
approximations that locate a superset of the apparent general races have been proposed [10, 11]. Such methods provide a means of debugging general of races in the programs using such synchronization, but have the potential misleading the programmer with potentially large numbers of spurious race reports.
5. CONCLUSION the nature of race conditions This paper explores memory parallel programs. By employing a formal
ously
hidden
issues
regarding
the
accuracy
and
that can arise in sharedmodel we uncover previ-
complexity
of dynamic
race
detection. We show that two fundamentally different types of races can occur: general races, pertaining to deterministic programs, and data races, pertaining to nondeterministic programs that use critical sections. We formally characterize these types of races. Previously, races have only been defined intuitively as occurring between data-conflicting blocks of code that “can potentially ACM
Letters
execute
concurrently”
on Programming
Languages
or whose and Systems,
Vol.
execution
order
1, No. 1, March
is not
1992.
“guaran-
What Are Race Conditions? teed. ” Our work orderings
that
properties
is novel
of the
detecting
in that
we explicitly
characterize
of occurring.
Doing
had the potential defined
them,
races,
depend
upon
such
which
as the sets
and
considered.
debugging
using
in practice.
the
of
uncover
two
notion of a race notion (the appar-
by most race detection methods. Since locating the feasible the less accurate apparent races must be relied upon for Moreover,
we uncover
complexity of debugging general races races requires exhaustively computing whether
because
complexity
We
variations of each type of race: one describes the intuitive (the feasible race) and the other describes a less accurate ent race) assumed races is NP-hard,
87
sets of alternative
so is important
accuracy
are
.
execution
fundamental
and data alternative
is nondeterministic),
synchronization
powerful
bugging data races requires fail), which can be efficiently
which
enough
is NP-hard
to implement
simpler analyses performed.
differences
in the
races. Debugging general orderings (to determine for programs
mutual
(to determine
exclusion.
if critical
De-
sections
REFERENCES 1. ALLEN,
T.
R.,
AND PADUA,
Proceedings
of the
Aug.
pp. 721-727.
1987),
2. BALASUNDARAM, parallel (Crete,
Greece,
C’omput. 4. CHOI,
V.,
program.
3. BERNSTEIN,
EC-15
J.-D.,
1989),
(Oct.
MILLER,
with
Debugging
K.
a shared
detection
International
memory
of
race
Conference
machine.
In
Charles,
IL,
(St.
Processing
conditions
in
a
on Supercomputing
175-185.
of programs
B.
in
on Parallel
Compile-time
of the 3rd
pp.
1966),
for
parallel
processing.
IEEE
Trans.
Electronic
for
debugging
757-763.
P.,
flowback
Fortran
Conference
KENNEDY,
Analysis
5
A.
Proceedings
June J.
D.
International
AND
In
A.
programs
1987
AND
analysis.
NETZER, ACM
R.
H.
‘Trans.
B.
Techniques
Program.
Lang.
Syst.
parallel
1991),
13, 4 (Oct.
491-530. 5. CHOI, J.-D., AND MIN, S. L. Race frontier: Reproducing data races in parallel program of the 3rd ACM Symposium on Principles and Practice of Parallel debugging. In Proceedings Programming 6. DINNING, lies
(Williamsburg,
on-the-fly.
7. DINNING, access
VA,
Apr.
A., AND SCHONBERG, E. IBM
A.,
Rep.
RC 15385, An
AND SCHONBERG, E.
anomaly
Practice
Tech.
detection.
of Parallel
1991),
The task
In
Jan.
145-154. technique
comparison
of the 2nd
(Seattle,
for detecting
WA, Mar.
of monitoring
ACM
Symposium
(Santa
Cruz,
CA,
P.
programs.
A.,
In
Debugging
May
1991),
(Madison,
D.
A.
Automatic
May
1988),
pp.
89-99.
(Jan. 1989). 10. EMRATH, P. A., GHOSH, S., AND PADUA, D. A. parallel
programs.
In
detection
of the SIGPLAN/SIGOPS
WI,
Charles,
R.,
12. HOOD, on-the-fly 1990),
IL,
Aug.
Proceedings
KENNEDY, anomaly
1990), K.,
detection.
in programs
with
and Distributed
critical
Debugging
of
of nondeterminacy
Workshop Also
Event
appears
’89
in
on Parallel in
and
SIGPLAN
synchronization
Supercomputing
580-588. 11. HEMLBOLD, D. P., MCDOWELL, C. E., AND WANG, J.-Z. of the 1990 International synchronization. In Proceedings
(St.
for and
pp. 79-90.
AND PADUA,
Proceedings
algorithms on Principles
1990), pp. 1-10.
8. DINNING, A., AND SCHONBERG, E. Detecting access anomalies of the ACM/ ONR Workshop on Parallel sections. In Proceedings 9. EMRATH,
access anoma-
1990.
empirical
Proceedings
Programming
pp.
recycling
Notices
analysis
(Reno,
Analyzing
NV,
24,
1
for debugging
NOV. 1989),
traces with
Conference
parallel
Distributed
on Parallel
PP.
anonymous Processing
pp. 70-77. AND In
MELLOR-CRUMMEY, Proceedings
J
Parallel
of Supercomputing
program
debugging
with
’90
York,
Nov.
(New
NY,
pp. 74-81. ACM
Letters
on Programming
Languages
and Systems,
Vol.
1, No. 1, March
1992.
88
R. H. Netzer and B. P. Miller
.
13. KARAM, G. M., STANCZYK, C. M., AND BOND, G, W. Trans.
Softw.
Eng.
14. LAMPORT, L. programs. tion.
How
IEEE
15. LAMPORT, J,
15, 11 (Nov.
L,
to make
Trans.
The
ACM
mutual
fork-join
J.
exclusion
M.
parallelism.
C-28
1986),
In
Critical
races in Ada programs.
IEEE
1471-1480.
a multiprocessor
Comput.
33, 2 (Apr.
16. MELLOR-CRUMMEY,
1989),
computer
9 (Sept.
problem:
that
1979), Part
correctly
executes
multiprocess
690-691.
I—A
theory
of interprocess
communica-
for
with
313-326.
On-the-fly
detection
Proceedings
of
data
races
of Supercomputing
programs
’91 (Albuquerquej
NM,
nested
Nov.
1991),
24-33. 17. MILLER, In
B. P., AND CHOI, J.-D.
Proceedings
mentation
A mechanism
for efficient
Conference
on Programming
of the SIGPLAN
(Atlanta,
GA, June
1988),
135 – 144. Also
debugging
of parallel
Language
appears
programs.
Design
and
Notices
23, 7 (July
in SIGPLAN
Imple-
1988). 18. MIN,
S. L.,
AND CHOI, J.-D.
Proceedings
of the 4th
Languages
and
An
Operating
20.
parallel
program (St.
NETZER,
R. H.
AND MILLER,
B.,
of the 3rd
(Williamsburg, 21.
VA,
NETZER,
R.
H.
B.
grams.
Computer
Aduances
T. Gross,
Apr.
1991),
Race
R,
with
I.,
NUDLER, programs.
1990),
detection
Support
1991),
scheme.
for
In
Programmmg
235-244.
of event
of the
1990
ordering
for shared-mem-
International
Conference
on
detection.
In
pp. II-93-II-97.
Improving
the
on Principles
accuracy and
of data
Practice
race
of Parallel
Programming
133-144. detection
for
Tech.
B. P.
debugging
Rep.
Eds.
Detecting
Compilers
MIT
AND GHOSH,
shared-memory
# 1039
Press S.
1991,
parallel
(Ph.D.
Thesis),
in parallel
program
pro-
Univ.
of
races
race
In IL,
L.
Tools
for
of the
Ist
Israeli
Processing,
A. Nicolau,
executions. D. Gelernter,
109-129.
Efficient
(St. Charles,
RUDOLPH,
Proceedings
data
for Parallel
synchronization.
Processing
AND
In
P.
Dept.
and
post/wait
ence on Parallel
B.
anomaly
1991.
D, Padua, B.,
Aug.
condition
Aug.
H,
IL,
pp.
CA, Apr. complexity
Proceedings
Symposium
in Languages
and
NETZER, programs
24.
ACM
NETZER, R. H. B., AND MILLER, In
23.
Charles,
access
on Architectural
Alto,
On the
In
Sciences
Wisconsin-Madison, 22.
executions.
Processing
Proceedings
(Palo
B. P.
Parallel
cache-based
Conference
Systems
19. NETZER, R. H. B., AND MILLER, ory
efficient
International
condition
Proceedings Aug.
the
detection
of the 1992
for
shared-memory
International
Confer-
1992), efficient
development
of
on
Computer
System
Reliability
issues
in
world.
In
Conference
efficient
parallel
Engineering
(1988). 25.
RANDELL, design.
26.
LEE,
STEELE, G. L.
P. A.,
Surv. Making
17th
Annual
Jan.
1990),
pp. 218-231.
April
1991;
Received
ACM
B.,
Comput.
Letters
ACM
AND TRELEAVEN,
10, 2 (June asynchronous
Symposium
revised
on Programming
1978),
parallelism
on Principles
October
Languages
P. C.
1991;
computing
system
123-165. safe for the
of Programming
accepted
and Systems,
February
Vol.
Languages
Proceedings (San Francisco,
1992
1, No. 1, March
1992.
of the CA,
