On Tue, 07 Oct 2008 02:33:00 -0700, JT <JT@discussions.microsoft.com>
wrote:
If I call Thread.Start am I guaranteed that thread will be running
before the
call from Thread.Start returns?
No, and in fact it would be unusual for it to do so. The started thread
will be runnable, but it won't get any CPU time until its turn in the
round-robin scheduling.
The thread that created the new thread will, unless it has exhausted its
own quantum in the act of creating the new thread (a statistical
improbability, though of course not impossible), continue running until it
yields or uses up its quantum. And of course, assuming it didn't exhaust
its own quantum while creating the new thread, neither of those conditions
will happen before the call from Thread.Start() returns. In most cases,
the existing thread will have plenty of time to do other things before the
newly created thread ever gets to run.
As Ciaran says, if the existing thread is in some way dependent on the
newly created thread, you can use thread synchronization objects such as a
WaitHandle implementation to control execution of each thread. That said,
it's unusual to need that sort of thing immediately after creating the new
thread. Normally, if there's something that the existing thread depends
on, you might as well do that thing in the existing thread rather than
relying and waiting on the newly created thread to do it.
In other words, if you find yourself in a situation where this is
important, you may have a design problem that needs fixing. Unnecessary
thread synchronization tends to hurt performance and as a general rule
negates any benefits that might have been had by using a multi-threaded
design in the first place.
Pete
