"An Unstarted thread is transitioned into the Running state by calling Start." [from msdn ThreadState enumeration docs.
Exactly when does a thread transition from Unstarted to Running?
If I instantiate a thread and call Start, is there a delay before the thread actually moves to Running? If the instantiating thread calls Join immediately after Start, is there a risk it'll catch the new thread in an Unstarted state?
Its state becomes Running before the Start() method returns, though it may not yet (and quite often will not) have done any actual work, as it may not yet have been given any core time. Most of the time the fact that we can think of the tread as running is enough (just as most of the time we can think "we have 6 threads running" when if we only have 4 cores the obviously we've only got up to 4 actually doing something). It could also be that by the time you get to the next instruction on the calling thread, that it's WaitSleepJoin or even Stopped but it won't be Unstarted.
It's perfectly safe to call Join() even in the very next statement after Start() (though that would rarely be useful).
The call to Start isn't asynchronous, so the method would return with the thread started. I've done this in a few sample apps and calling Join immediately afterwards never caused any problems.
The documentation for ThreadState.Unstarted states
Unstarted The Thread::Start method has not been invoked on the thread.
In other words, no, you can't end up with Thread.Unstarted after Thread::Start has been called. The Thread is not guaranteed to be in ThreadState.Running though, it could be in for example ThreadState.WaitSleepJoin if it blocks on a Mutex before you check the state.
The only ThreadState that causes problems with Join is ThreadState.Unstarted though, so calling Join is safe right after Start, provided Start does not throw an exception.
Related
Thread.Sleep. Suspends the current thread what does that mean?
What does this mean physically? What does a thread do? It cannot be said that the thread does nothing because the method itself is executed and the thread must do something, and if the thread does something, then it is not suspended or is it not?
Modern operating systems can assign CPU time to multiple processes, each of which may contain multiple threads.
A component often called a scheduler is responsible for this.
Calling Thread.Sleep() informs the scheduler that the thread on which the call is made should not run until at least a specified amount of time has passed. The scheduler will use that information to allocate CPU time to other threads.
Thread.Sleep. Suspends the current thread what does that mean?
From the application's point of view it's simple. Thread.sleep(n) does nothing. It does it for n milliseconds, and then it returns.
What does this mean physically?
On a multi-tasking operating system (e.g., most desktop, server, or mobile-device platforms) it means that the OS scheduler allows the CPU that the thread was running on to be used for other things during the next n milliseconds. If there are no other threads at that moment that are ready to run, then the scheduler allows a special "idle loop" to run on it. The "idle loop" puts the CPU into a low-power state until it gets an interrupt signifying that the CPU is needed again.
What does a thread do?
Think of a thread as an agent who executes your code.
It cannot be said that the thread does nothing because the method itself is executed...
You can say that if you wish. The sleep() function "does nothing" in the sense that it doesn't cause the CPU to do any work, it has no side effects, and it returns no value. But I guess it makes sense to say that the thread is "doing something" during the sleep() interval. Specifically, what the thread is doing is, it is sleeping. More broadly speaking, the thread is executing your code, which just that that exact moment, is telling the thread to sleep.
..., and if the thread does something, then it is not suspended or is it not?
Suppose you are planting a garden. It's going to take you all day, but at some point, you have to take a break and get some water. Your phone rings just at that moment and your friend asks, "Yo Bro! What's up?" Would it be acceptable for you to say, "I'm planting a garden...?" IMO you could say that. Or, you could say, "I'm taking a break from planting a garden," or if you wanted to be a smart-ass, you could say "I'm talking to you on the phone." All three of those arguably are true statements.
You taking a break to get some water is kind of like a thread being "suspended."
Thread.Join and waitHandle.WaitOne(), both of them force the calling thread to wait. Until the thread has finished executing and until the waitHandle.Set() is called respectively.
But is there any difference between the 2 besides this?
...both of them force the calling thread to wait until the called
thread has finished executing.
No, they don't. They are completely different.
WaitHandle.WaitOne will block the calling thread until the wait handle is signaled.
Thread.Join will block the calling thread until the thread object which the Join method is called is finished executing(terminated)
#helloworld, A distinction is "at the end of the method". Unless your method catches all exceptions, it may exit due to unhandled exception (e.g. due to thread.abort), before your call to WaitHandle.Set().
WaitHandles require cooperation/knowledge between threads. The called thread has to be passed the wait handle, and it has to signal at the appropriate time. It is useful, when two threads are sharing a resource such as a pub-sub queue.
WaitHandles are just one of many signaling/locking mechanisms. Semaphores, mutexes, lock files and even thread-shared variables (accessed carefully, e.g. Interlocked.Increment) can be used for signaling.
Thread.Join - does not require any cooperation from the called thread. When the called thread is done for any reason, including abnormal termination, join returns.
Thread.Join is more like Process.Wait. Process.Wait returns when the process terminates for any reason.
In short, if you need to know when a thread terminates for any reason, use Thread.Join.
When you need to know if a thread has executed to a certain point, use signaling.
I was curious as to how Thread.Sleep was implemented. I had a look with Reflector for the implementation of Thread.Sleep. It calls the following function:
[MethodImpl(MethodImplOptions.InternalCall), SecurityCritical]
private static extern void SleepInternal(int millisecondsTimeout);
Does anyone know where that is defined? I am aware of other alternatives, such as Task.Delay. But was curious as to the actual implementation details.
Joe Duffy's book Concurrent Programming provides all of the details you need. But to summarize:
Thread.Sleep behaves similar to the Win API function SleepEx.
A duration parameter = 0 will cause the current thread to yield to another with equal or higher priority.
A duration parameter > 0 will cause a context switch and the current thread will remain in a Waiting state for until the specified amount of time has elapsed (approximately).
The thread will remain in an alertable state which means it is allowed to process APC methods via QueueUserAPC and will respond to Thread.Interrupt calls.
I recommend poking through the SSCLI code for a more complete understanding of how it is implemented.
Regarding your question about not being able to reuse the thread for other work...I am a bit confused. Thread.Sleep is a voluntary suspension so you (the programmer) told the thread not to do any more work. And like I mentioned above the thread is said to be alertable so you could actually interrupt it or even force it to do work via APC methods.
Refer to this question for more information about getting .NET threads to run APCs while Thread.Sleep is still pending.
Thread.Sleep() when called by a system thread (a real thread, not a user-thread) is a call that hooks into the OS kernel scheduling internals, similar to process sleep. It puts the execution context (that is visible at the kernel process level) into a "sleep" wait state so it consumes no CPU until it wakes up. It isn't a busy wait.
If you want it to be awake and/or doing other things, use some other mechanism besides Thread.Sleep().
Use await Task.Delay() if you want the thread to be reused
I have a method void DoWork(object input) that takes roughly 5 seconds to complete. I have read that Thread is better suited than ThreadPool for these longer operations but I have encountered a problem.
I click a button which calls threadRun.Start(input) which runs and completes fine. I click the button again and receive the following exception:
Thread is running or terminated; it cannot restart.
Can you not "reuse" a Thread? Should I use ThreadPool? Why is Thread "better suited for longer operations" compared to ThreadPool? If you can't reuse a thread, why use it at all (i.e. what advantages does it offer)?
Can you not "reuse" a Thread?
You can. But you have to code the thread not to terminate but to instead wait for more work. That's what a thread pool does.
Should I use ThreadPool?
If you want to re-use a thread, yes.
Why is Thread "better suited for longer operations" compared to ThreadPool?
Imagine a thread pool that is serving a large number of quick operations. You don't want to have too many threads, because the computer can only do so many things at a time. Each long operation you make the thread pool do ties up a thread from the pool. So the pool either has to have lots of extra threads or may run short of threads. Neither leads to an efficient thread pool design.
For longer operations, the overhead of creating and destroying a thread is very small in comparison to the cost of the operation. So the normal downside of using a thread just for the operation doesn't apply.
If you can't reuse a thread, why use it at all (i.e. what advantages does it offer)?
I'm assuming you mean using a thread dedicated to a job that then terminates over using a thread pool. The advantage is that the number of threads will always equal the number of jobs this way. This means you have to create a thread every time you start a job and destroy a thread every time you finish one, but you never have extra threads nor do you ever run short on threads. (This can be a good thing with I/O bound threads but can be a bad thing if most threads are CPU bound most of the time.)
Thread.Start documentation says:
Once the thread terminates, it cannot be restarted with another call
to Start.
Threads are not reusable. I have already faced this problem a while ago, the solution was to create a new Thread instance whenever needed.
It looks like this by by design.
I encountered the same problem and the only solution I could find was to recreate the thread. In my case I wasn't restarting the thread very often so I didn't look any further.
A search now has turned up this thread on social.msdn where the accepted answer states:
a stopped or aborted thread cannot be stated again.
The MSDN repeat this as well:
trying to restart an aborted thread by calling Start on a thread that has terminated throws a ThreadStateException.
As the message states, you cannot restart the thread. You can simply create a new thread for your next operation. Or, you might consider a design where the background thread keeps working until it completes all of your tasks, rather than launch a new thread for each one.
for(;;){} or while(true){} are useful constructs to 'reuse' a thread. Typically, the thread waits on some synchronization object at the top of these loops. In your example, you could wait on an event or semaphore and signal it from your button OnClick() handler.
It's just in background mode. It sounds like you need to use the ThreadPool because re-starting and re-creating Thread objects are very expensive operations. If you have a long running job that may last longer than your main process, then consider the use of a Windows Service.
I am using asynchronous methods in some of my project and I like it since it allows my application to be a lot more scalable. However, I am wondering how asynchronous methods really work in background? How .NET (or Windows?) knows that a call is completed? Depending on the number of asynchronous calls I made, I can see that new threads are created (not always though…). Why?
In addition, I would like to monitor how long a request take to complete. To test the concept, I wrote the following code which calls asynchronously a Web service and immediately after starts a stopwatch.
for (int i = 0; i < 10000; i++)
{
myWebService.BeginMyMethod(new MyRequest(), result, new AsyncCallback(callback), i);
stopWatches[i].Start();
}
// Call back stop the stopwatch after calling EndMyMethod
This doesn’t work since all the requests (10000) have the same begin time and the duration will go up linearly (call 0 = duration 1, call 1 = duration 2, etc.). How could I monitor the real duration of a call with asynchronous method (from the moment the request is really executed until the end)?
UPDATE: Does an asynchronous method block the flow? I understand that it uses the .NET ThreadPool but how an IAsyncResult know that a call is completed and it's time to call the CallBack method?
The code is the railroad and the thread is the train. As train goes on railroad it executes the code.
BeginMyMethod is executed by the main thread. If you look inside the BeginMyMethod it simply adds a delegate of MyMethod to the ThreadPool's queue. The actual MyMethod is executed by one of the trains of the train pool. The completion routine that is called when MyMethod is done is executed by the same thread that executed the MyMethod, not by your main thread that runs the rest of the code. While a thread pool thread is busy executing MyMethod, the main thread can either ride some other portion of the railroad system (execute some other code), or simply sleep, waiting until certain semaphore is lit up.
Therefore there's no such thing as IAsyncResult "knowing" when to call the completion routine, instead, completion routine is simply a delegate called by the thread pool's thread right after it's done executing MyMethod.
I hope you don't mind the somewhat childish train analogy, I know it helped me more than once when explaining multithreading to people.
The crux of it is that calling Begin queues up a request to execute your method. The method is actually executed on the ThreadPool, which is a set of worker threads provided by the runtime.
The threadpool is a fixed set of threads to crunch through async tasks as they get put into the queue. That explains why you see the execution time take longer and longer - your methods may each execute in approximately the same time, but they don't start until all previous methods in the queue have been executed.
To monitor the length of time it takes to actually execute the async method, you have to start and stop the timer at the beginning and end of your method.
Here's the docs for the ThreadPool class, and an article about async methods that do a better job of explaining what's going on.
Asynchronous methods work by using the .NET ThreadPool. They will push the work onto a ThreadPool thread (potentially creating one if needed, but usually just reusing one) in order to work in the background.
In your case, you can do what you're doing, however, realize that the ThreadPool has a limited number of threads with which it will work. You're going to spawn your work onto background threads, and the first will run immediately, but after a while, they will queue up, and not work until "tasks" run before completely. This will give the appearance of the threads taking longer and longer.
However, your stopwatch criteria is somewhat flawed. You should measure the total time it takes to complete N tasks, not N times to complete one task. This will be a much more useful metric.
Its possible that a majority of the execution time happens before BeginMyMethod(). In that case your measurement will be too low. In fact, depending on the API, BeginMyMethod() may call the callback before leaving the stack itself. Moving up the call to StopWatch.Start() should help then.