ThreadChecker: Reported errors that look ok to me

[Deleted_U_Intel]

I am evaluating Thread Checker. I ran our app under it and got a long list of errors reported. I'm trying to understand what the errors mean. I've come across a couple cases that I'm pretty sure are guaranteed safe and wondered what I can do about them.

1) To abort a thread from another thread, I have a variable that is shared by both threads that I write in one thread and read in another. That is:

bool bStop = false;

Thread 1:

bStop = true;

Thread 2:

while (!bStop)
{
// do one iteration
}

As I understand it, a bool is the same size as an int, and should be written atomically, so there shouldn't be any synchonization issues. Am I wrong? Is there really a problem with this technique? If not, can I suppress this error?

2) At program start up, I need to read a bunch of files and process them to set up some variables that remain constant for the rest of the run of my program. I do this in a separate thread so that I can put up a progress dialog with a "Cancel" button. I don't allow my app to continue until the thread is finished. That is:

StartInitializationThread();
WaitUntilInitializationFinished();
// read the variable set in the initialization thread.

This causes a message saying I could have a race condition, but I'm sure that I don't read the variable until the initialization thread no longer exists. Is there a way to tell Thread Checker that? Alternately, is there a way I could write the code that would not result in the message? It seems like a waste to put CCriticalSections in that will never be needed.

Message Edited by DaveA on 07-07-2004 10:27 AM

[Jason_P_Intel]

Although use of a shared memory location to signal state transitions is logically correct in both of your cases, Thread Checker cannot determine how you are using the data and reports that thread2 read the location before (read->write) and after (write->read) it was written by thread1. We refer to this type of benign diagnostic as a false positive.

We are investigating ways to enhance the Intel Thread Checker to allow suppression of false positives once they are deemed safe by the user.

A more elegant solution that ensures explicit synchronization is to use the standard Windows APIs. Rewriting your first case using the standard Windows synchronization primitives would look like this:

HANDLE bStop = CreateEvent(0,0,0,0);

Thread1:
SetEvent( bStop );

Thread2:
while ( ! ( WaitForSingleObject( bStop, 20 ) == WAIT_OBJECT_0 ) ) // Become inactive for 20 ms or until bStop is set.

{

//

}

Here the WaitForSingleObject call waits for the bStop signal for 20ms. If this value is 0, the function tests for the signal and returns immediately, however a value of 20ms could improve the throughput and responsiveness of other threads that are running in parallel.

In your second case, you might try the same technique with a special timeout value of INFINITE and either wait on the thread handle (join) or for a signal that is sent after the initialization is complete.