Why is creating a new thread expensive?

Question

I read lots of .Net resources telling me that I should be using a thread pool thread rather than instantiating a new thread myself. They say you should do this because instantiating a new thread is an expensive operation. What happens during thread creation that makes it an expensive operation?

Answer 1

Everything is relative. Creating a new thread is expensive... relative to not creating one. If you're not doing a lot of work per thread, the work involved in building and tearing down the threads can potentially make up a measurable portion of your cpu time. But it's cheap relative to creating a new process, especially on Windows.

It's also generally better to use the threadpool because it is tuned to help you avoid having too many threads active at once. You rarely want more than a handful of threads active at one time, or you'll spend a lot of cpu time performing context-switches between them all. Using the threadpool manages this for you, as additional requests are queued until a worker thread is ready.

Answer 2

Each thread by default gets 1 MB of memory allocated. That can quickly get expensive.

Answer 3

There are a couple of factors. One that's been mentioned is memory for the stack. Because stack memory is not handled by the normal GC allocator used for objects, creating a thread's stack and then abandoning it is very different from creating a megs worth of heap objects and abandoning them.

Another factor not yet mentioned is the cost associated with things like threadstatic variables. In some systems which require all thread-static variables a thread might use to be defined before the thread starts, starting a new thread would require initializing all thread-static variables. Because .net allows threads to dynamically add threadstatic variables, the data structures used are different. Nonetheless, initializing such data structures when a thread starts is not free.

Answer 4

Threadpool is not only about amortizing the cost of thread creation and destruction and not only about saving memory with less stacks. The real benefit of it avoids having too many active threads at the same time, and minimizing context switches if you run server application. Even if you are not writing server application, threadpool just a nicer abstraction than thread - start async operation, get notification when finished, or execute a callback when finished, and let OS or runtime figure out how many threads to create.