Win NT ThreadPool

How much overhead is involved in creating a new thread in Windows NT?  If I have an application that will start up sessions, each of which will use a thread, is there any advantage in creating a ThreadPool object to pre-allocate and then dispense these threads?  Is it efficient enough just to create and destroy threads as needed?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

There is quite a lot of overhead in creating threads.  Numerious tasks need to be done.  It needs a message queue, an entry has to be made in numerious "databases" that record thread information.  A task state structure needs to be created and initialized.  In C++ the RTL needs to be initialized for each thread.   Much more Most of this stuff needs to be reversed when the thread terminates.  

So there is a lot of overhead, but compared to what?  How long will the threads run?  What will they be doing.  If the thread does a lot of work, the the creation/destruction time is not signficant.  If it doesn't do a lot of work it may be significant, but you also might be better of not adding threads.

Let me know if you have any questions, of if you want to provide more info.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mcglincheyAuthor Commented:
In particular, I'm interested in knowing if the overhead is appreciable compared with the overhead of maintaining a thread pool; eg a thread pool will need to maintain a semaphore, and will keep more threads than necessary in idle state.

To be concrete: the session may last for 5 minutes (so a thread's life might average ~ 5 minutes). There may be say 30 threads in a pool, and that would be the maximum expected # of sessions.  Most of the time, though, 80% of those threads will be idle.

Do you have a feeling for if keeping the threads' resources around and idle is more costly than the cost of creating and destroying threads as they're needed?
For thread lives of that sort of length, you will not see any measurable benefit to having a thread pool.  The thread's useful length is 3 or 4 order of magnitude more than the time needed to create the thread.  (remember the 80-20 rule.  Even if it was the 1--99 rule, a thread pool wouldn't help.)

Futhermore, with that many threads (30) you would almost certainly be better off not having the threads sitting around doing nothing.  There is some cost to having suspended threads (Idle thread threads are obviously costly, but suspended ones are too.) and the more threads, the more the cost.  Note also that NT seems to have no problem with so many threads in a process (although it will be costly) Windows 95 would almost certainly not do well with so many threads in a process (things tend to break down in the 7-10 thread vicinity.)  I don't know if that matters to you
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.