views:

59

answers:

3

When myThread.Start(...) is called, do we have the assurance that the thread is started? The MSDN documentation isn't really specific about that. It says that the status of is changed to Running.

I am asking because I've seen a couple of times the following code. It creates a thread, starts it and then loop until the status become Running. Is that necessary to loop?

Thread t = new Thread(new ParameterizedThreadStart(data));
t.Start(data);
while (t.ThreadState != System.Threading.ThreadState.Running &&
       t.ThreadState != System.Threading.ThreadState.WaitSleepJoin)
{
     Thread.Sleep(10);
}

Thanks!

+2  A: 

Guess it depends on what you are doing after the loop. If whatever comes after it critically dependant on the thread running then checking is not a bad idea. Personnally I'd use a ManualResetEvent or something similiar that was set by the Thread rather than checking the ThreadStatus

John Bergess
+1  A: 

No. Thread.Start causes a "thread to be scheduled for execution". It will start, but it may take a (short) period of time before the code within your delegate actually runs. In fact, the code above doesn't do what (I suspect) the author intended, either. Setting the thread's threadstate to ThreadState.Running (which does happen in Thread.Start) just makes sure it's scheduled to run -- but the ThreadState can be "Running" before the delegate is actually executing.

As John Bergess suggested, using a ManualResetEvent to notify the main thread that the thread is running is a much better option than sleeping and checking the thread's state.

Reed Copsey
+1  A: 

If you're set on not allowing your loop to continue until the thread has "started", then it will depend on what exactly you mean by "started". Does that mean that the thread has been created by the OS and signaled to run, but not necessarily that it's done anything yet? Does that mean that it's executed one or more operations?

While it's likely fine, your loop isn't bulletproof, since it's theoretically possible that the entire thread executes between the time you call Start and when you check the ThreadState; it's also not a good idea to check the property directly twice.

If you want to stick with checking the state, something like this would/could be more reliable:

ThreadState state = t.ThreadState;

while(state != ThreadState.Runnung && state != ThreadState.WaitSleepJoin)
{
    Thread.Sleep(10:

    state = t.ThreadState;
}

However, this is still subject to the possibility of the thread starting, running, then stopping before you even get the chance to check. Yes, you could expand the scope of the if statement to include other states, but I would recommend using a WaitHandle to signal when the thread "starts".

ManualResetEvent signal;

void foo()
{
    Thread t = new Thread(new ParameterizedThreadStart(ThreadMethod));

    signal = new ManualResetEvent();

    t.Start(data);

    signal.WaitOne();

    /* code to execute after the thread has "started" */
}

void ThreadMethod(object foo)
{
    signal.Set();

    /* do your work */
}

You still have the possiblity of the thread ending before you check, but you're guaranteed to have that WaitHandle set once the thread starts. The call to WaitOne will block indefinitely until Set has been called on the WaitHandle.

Adam Robinson
Thanks! I like this idea and... the example!
Martin