New Thread or ThreadPool?

  • Thread starter Thread starter Curious
  • Start date Start date
C

Curious

Hi,

I have a large application that currently uses a timer at an interval
of 15 seconds.

At the beginning of every 15 seconds, it launches a big task. I worry
that it won't be able to finish such a big task in such a short time
period before the timer launches a new task in 15 seconds.

Therefore, I plan to start a new thread to do some work in order to
reduce the workload on the timer thread. Now I'm picking between the
following two:

//Option 1:
Thread newT = new Thread(new ThreadStart(DoSomeWork));
newT.Start();

//Option 2:
ThreadPool.QueueUserWorkItem(new WaitCallBack(DoSomeWork), null);

Anyone can advise me on which option I should use?
 
Using thread pool is better option. If you use any thread from thread pool,
then whenever a thread get freed, it will automatically added to the pool
and availble for reuse.
________________________
(e-mail address removed)
http://www.dailycoding.com/
DailyCoding.com - dailt code for C#, .NET, ASP.NET, SQL
 
Using thread pool is better option. If you use any thread from thread pool,
then whenever a thread get freed, it will automatically added to the pool
and availble for reuse.
Click to expand...

Thanks! I'll use thread pool.
 
Thanks! I'll use thread pool.
Click to expand...

Not so fast! I disagree with the use of the ThreadPool in your case.
You said that you want to kick off a task that may not even complete
within 15 seconds. That's *way* too long to tie up a thread from the
ThreadPool. Remember, the ThreadPool may be used for things that you
are unaware of and you certainly don't want to overload it with work
that you could easy put on a dedicated thread.
 
Not so fast!  I disagree with the use of the ThreadPool in your case.
You said that you want to kick off a task that may not even complete
within 15 seconds.  That's *way* too long to tie up a thread from the
ThreadPool.  Remember, the ThreadPool may be used for things that you
are unaware of and you certainly don't want to overload it with work
that you could easy put on a dedicated thread.
Click to expand...

Are you saying that if a task is complicated, use Thread instead of
thread pool? What are the differences between thread and thread pool
exactly?

What if I need to show a message box periodically, shall I use thread
or thread pool? If the user is in a long meeting and doesn't click
"OK" button to dismiss the message box, potentially there may be whole
bunch of message boxes clustered on the screen.

Thanks! I'll use Thread then.
 
Are you saying that if a task is complicated, use Thread instead of
thread pool? What are the differences between thread and thread pool
exactly?
Click to expand...

Thread represents a single logical thread of execution. ThreadPool is
a manager for a pool of threads that are always available to execute
work items. The advantage of the ThreadPool is that it keeps its
constituent threads initialized and running so that they can begin
executing work items immediately as they arrive. There would be no
overhead for creating a new thread and getting it running. The caveat
is that it works better if the work items can be completed quickly so
that the threads executing them can return to the pool in a timely
manner.

Think about it this way. Assume that it takes 100 CPU cycles to
initialize a new thread. Now assume that your work item takes 100 CPU
cycles to complete. The ratio of overhead to actual work is a
whopping (and unappealing) 0.5. Now assume your work item takes
10,000 cycles to complete. The ratio is now only 0.005. So in the
first example you could cut the execution time in half by using the
ThreadPool instead of spinning up a new Thread. But, in the second
example the benefit is negligible. In other words, spinning up a new
Thread in the second example doesn't effect performance all that much.
What if I need to show a message box periodically, shall I use thread
or thread pool? If the user is in a long meeting and doesn't click
"OK" button to dismiss the message box, potentially there may be whole
bunch of message boxes clustered on the screen.
Click to expand...

ThreadPool versus Thread is irrelevant in this case. The execution of
your work item is a non-UI thread period. Special care needs to be
taken when attempting to interact with the UI from a non-UI thread.
In fact, you can't technically do anything to the UI (show a message
box or even read a Form variable) from a thread other than the UI
thread. If you want the work item to signal or communicate to the UI
thread then you need to marshal the execution of a method onto the UI
thread. This can be done via the Control.Invoke or
Control.BeginInvoke methods.
 
Thanks Brian for the answer!

Now I understand that for a bigger task, it doesn't make much
difference if I were to use a thread or thread pool.

If there a limit on how many threads I can start? I assume that if
they are not started at the same time, those would be automatically
disposed by .NET if the work associated with the thread is completed.

My application is different from a UI application. It's a back-end
plug-in to an existing application with UI. It's almost impossible to
display any UI item from my back-end plug-in. However, with a new
thread, I'm able to show message boxes.
 
Thanks Brian for the answer!

Now I understand that for a bigger task, it doesn't make much
difference if I were to use a thread or thread pool.
Click to expand...

Correct. In addition, the disadvantage of using the ThreadPool for
longer running work items is that the threads in the pool will take
longer to return to the pool. That might affect the performance of
other unrelated work items that may be waiting in the queue.
If there a limit on how many threads I can start?
Click to expand...

Yes. All threads consume system resources (stack space is probably
the most obvious) so at some point the system will be severely
impacted.
I assume that if
they are not started at the same time, those would be automatically
disposed by .NET if the work associated with the thread is completed.
Click to expand...

Generally speaking yes. I don't know all of the details, but once the
method being executed by a Thread ends (or is interrupted by an
exception) then the resources being consumed by that that Thread are
returned to the system.
My application is different from a UI application. It's a back-end
plug-in to an existing application with UI. It's almost impossible to
display any UI item from my back-end plug-in. However, with a new
thread, I'm able to show message boxes.
Click to expand...

So you're showing a message box from a worker thread then? That's all
the more reason to not to use the ThreadPool. Since message boxes are
modal they will block the execution of the caller until a user closes
the form. Honestly, I've never used a message box from a worker
thread so I don't know what the specific consequences are, but the
Show method is injecting a message loop on the calling thread to
facilitate its display so MessageBox is somewhat of a unique case.
That probably explains why it is working for you.
 
Hi Brian,

You sound knowledgable about multi-threading. May I ask a you a
question - I have a timer, mTimer, that runs every 15 seconds.
However, I'll only need the timer for 30 minutes. I want to destroy
mTimer after it's run for 30 minutes. May I call "mTimer.Dispose()"
from it callback? Will this cause a crash or something? FYI, my code
is below:

mTimer = new System.Threading.Timer (new
TimerCallBack(SubscribeTrade), null, 15000, 15000);


void SubscribeTrade (object state)
{
DateTime now = DateTime.Now;
TimeSpan elapsed = now.Subtract(mStartTime);
int minutes = elapsed.Minutes;

if (minutes <= 30)
{
//Code omitted here
}
else // Need to destroy the timer after 30 minutes here
{
// Is this the right way to destroy the timer object?
mTimer.Dispose();
}
}
 
Hi Brian,

You sound knowledgable about multi-threading. May I ask a you a
question - I have a timer, mTimer, that runs every 15 seconds.
However, I'll only need the timer for 30 minutes. I want to destroy
mTimer after it's run for 30 minutes. May I call "mTimer.Dispose()"
from it callback? Will this cause a crash or something? FYI, my code
is below:

mTimer = new System.Threading.Timer (new
TimerCallBack(SubscribeTrade), null, 15000, 15000);

void SubscribeTrade (object state)
{
    DateTime now = DateTime.Now;
    TimeSpan elapsed = now.Subtract(mStartTime);
    int minutes = elapsed.Minutes;

    if (minutes <= 30)
    {
        //Code omitted here
    }
    else // Need to destroy the timer after 30 minutes here
    {
        // Is this the right way to destroy the timer object?
        mTimer.Dispose();
    }



}
Click to expand...

I believe that's okay, but to be sure go ahead and try it out see for
yourself.
 
Back
Top