Add Shared Memory Race Detection

[GoogleCodeExporter]

Describe the New Feature:

From SPWorley:

Just had a little brainstorm... not a feature request, but something
that may inspire some more memory debugging/error checking for
Ocelot's emulator.

It could be straightforward for Ocelot to detect all shared memory
thread race conditions.  These happen when one thread writes to shared
memory and a different thread reads, but with unspecified thread
ordering, that read may have occurred either before or after the write
so your results become uncertain. These bugs are usually hard to track
down since they often work and break only later when some other
innocuous change is made.

Ocelot could detect these shared memory ordering races pretty easily
with a little overhead in memory and time.

Allocate two 16K int (or short) buffers.. these are basically two
tracking variables per shared memory location to track which thread
has read or written to a particular byte of shared memory.  At the
start of a block and every threadsync(), initialize the two buffers to
0xFFFF, meaning "no access yet."
If a thread reads from a shared memory location, mark the "read"
buffer with the thread ID.  If a thread writes to a shared memory
location, mark the "write" buffer with that thread ID.

Typical race errors will be detected by checking that the read and
write arrays never have two different thread IDs in them.  It's OK if
one thread reads and writes. It's OK if lots of threads read and
nobody writes. It's even OK if lots of threads write and nobody
reads.   But once you detect that you have a reader and writer with
different thead IDs, you fire off the "warning, potential race
condition detected."

If multiple threads read, then you could mark the array with a
"multiple readers" flag instead of the threadID and then *ANY* write
before or after would be a race. Same for multiple writers.

This idea may not be too practical or important but I thought I'd
share it while it was still fresh in my mind.

Which milestone does the feature belong to?
2.0.x

Which branch does the new feature go in?
Trunk

Original issue reported on code.google.com by gregory....@gatech.edu on 29 Oct 2009 at 3:03

[GoogleCodeExporter]

Added a preliminary version of this for the emulator, using only a single array 
and
an invalid flag for each byte.

Original comment by gregory....@gatech.edu on 27 Jan 2010 at 10:17

[GoogleCodeExporter]

Original comment by gregory....@gatech.edu on 27 Jan 2010 at 10:17

• Changed state: Fixed