Starting a new Thread vs. ThreadPool

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads. My questions;
1. what's the difference?
There are only 25 threads in the threadpool, code queued to execute must
await the termination of a running thread in the pool.

This means that you could get into a starvation situation where none of
the threads in the pool terminate because the threads that updates the
state so they can continue cannot run :)

If you had started a thread instead you might have 1000s of them
running, and you get an error when you try to *start* the thread, not a
deadlock.
2. Any performance benefits?
Try a profiler, post it here if you find any difference worth
mentioning. Remember that (hopefully) less that 1% of your code is
spawning threads, so you only get very little of any bechmarked improvement.
3. Can ThreadPool be used for the above-mentioned design pattern?
You are *already* using the threadpool in the exact way it's meant to be
used: to run short pieces of code that will soon terminate. .BeginInvoke
queues execution on the threadpool.
If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.

There is no code for which it should or must be used, let the compiler
use it for .BeginInvoke.

Do not use it for things that you expect to block, waiting for other
threads.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads. My questions;
1. what's the difference?
There are only 25 threads in the threadpool, code queued to execute must
await the termination of a running thread in the pool.

This means that you could get into a starvation situation where none of
the threads in the pool terminate because the threads that updates the
state so they can continue cannot run :)

If you had started a thread instead you might have 1000s of them
running, and you get an error when you try to *start* the thread, not a
deadlock.
2. Any performance benefits?
Try a profiler, post it here if you find any difference worth
mentioning. Remember that (hopefully) less that 1% of your code is
spawning threads, so you only get very little of any bechmarked improvement.
3. Can ThreadPool be used for the above-mentioned design pattern?
You are *already* using the threadpool in the exact way it's meant to be
used: to run short pieces of code that will soon terminate. .BeginInvoke
queues execution on the threadpool.
If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.

There is no code for which it should or must be used, let the compiler
use it for .BeginInvoke.

Do not use it for things that you expect to block, waiting for other
threads.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.
My questions; 1. what's the difference?
The ThreadPool is managed by the framework. It is a fixed size pool of
threads that the framework uses to run work items asynchronously. It's
very easy to use. You simply make a call to
ThreadPool.QueueUserWorkItem and pass in a delegate of the method you
want to run.
2. Any performance benefits?
Yes, especially for work items that execute quickly. Since the threads
have already been created there is little overhead in getting a work
item to execute.
3. Can ThreadPool be used for the above-mentioned design pattern?
It depends. If the task you're wanting to run asynchronously takes a
long time to complete then no. You're better off managing your own
worker thread. If the task completes very quickly then it might be a
candidate. If you could explain what your existing worker thread does
then we could offer better advice.
If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.
Thank you

Like I said, generally tasks that complete quickly are candidates.

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.
My questions; 1. what's the difference?
The ThreadPool is managed by the framework. It is a fixed size pool of
threads that the framework uses to run work items asynchronously. It's
very easy to use. You simply make a call to
ThreadPool.QueueUserWorkItem and pass in a delegate of the method you
want to run.
2. Any performance benefits?
Yes, especially for work items that execute quickly. Since the threads
have already been created there is little overhead in getting a work
item to execute.
3. Can ThreadPool be used for the above-mentioned design pattern?
It depends. If the task you're wanting to run asynchronously takes a
long time to complete then no. You're better off managing your own
worker thread. If the task completes very quickly then it might be a
candidate. If you could explain what your existing worker thread does
then we could offer better advice.
If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.
Thank you

Like I said, generally tasks that complete quickly are candidates.

Helge Jensen wrote:

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.

My questions;
1. what's the difference?

There are only 25 threads in the threadpool, code queued to execute must
await the termination of a running thread in the pool.

This means that you could get into a starvation situation where none of
the threads in the pool terminate because the threads that updates the
state so they can continue cannot run :)

If you had started a thread instead you might have 1000s of them
running, and you get an error when you try to *start* the thread, not a
deadlock.

2. Any performance benefits?

Try a profiler, post it here if you find any difference worth
mentioning. Remember that (hopefully) less that 1% of your code is
spawning threads, so you only get very little of any bechmarked improvement.

3. Can ThreadPool be used for the above-mentioned design pattern?

You are *already* using the threadpool in the exact way it's meant to be
used: to run short pieces of code that will soon terminate. .BeginInvoke
queues execution on the threadpool.

The OP is not using the ThreadPool currently. The BeginInvoke method
the OP is speaking of is actually ISynchronizeInvoke.BeginInvoke. When
used on a Form or Control this method marshals the execution a of
delegate onto the thread hosting that form or control (the UI thread).
In this case execution is queued and executed by the message loop.

If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.

There is no code for which it should or must be used, let the compiler
use it for .BeginInvoke.

Do not use it for things that you expect to block, waiting for other
threads.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Helge Jensen wrote:

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.

My questions;
1. what's the difference?

There are only 25 threads in the threadpool, code queued to execute must
await the termination of a running thread in the pool.

This means that you could get into a starvation situation where none of
the threads in the pool terminate because the threads that updates the
state so they can continue cannot run :)

If you had started a thread instead you might have 1000s of them
running, and you get an error when you try to *start* the thread, not a
deadlock.

2. Any performance benefits?

Try a profiler, post it here if you find any difference worth
mentioning. Remember that (hopefully) less that 1% of your code is
spawning threads, so you only get very little of any bechmarked improvement.

3. Can ThreadPool be used for the above-mentioned design pattern?

You are *already* using the threadpool in the exact way it's meant to be
used: to run short pieces of code that will soon terminate. .BeginInvoke
queues execution on the threadpool.

The OP is not using the ThreadPool currently. The BeginInvoke method
the OP is speaking of is actually ISynchronizeInvoke.BeginInvoke. When
used on a Form or Control this method marshals the execution a of
delegate onto the thread hosting that form or control (the UI thread).
In this case execution is queued and executed by the message loop.

If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.

There is no code for which it should or must be used, let the compiler
use it for .BeginInvoke.

Do not use it for things that you expect to block, waiting for other
threads.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Brian Gideon wrote:

Helge Jensen wrote: The OP is not using the ThreadPool currently. The BeginInvoke method
the OP is speaking of is actually ISynchronizeInvoke.BeginInvoke.

I see.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Brian Gideon wrote:

Helge Jensen wrote: The OP is not using the ThreadPool currently. The BeginInvoke method
the OP is speaking of is actually ISynchronizeInvoke.BeginInvoke.

I see.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Thank you all,

From what I am hearing ThreadPool will not make my life easier in any form.
So far, I developed a few .NET applications, that automate certain production
tasks. Mostly has to do with pulling data from SQL Server and/or legacy file
server, processing it, and generating reports. So, I usually start a worker
thread that in turn makes calls to different objects that do all those
smaller tasks, worker thread raises events when certain tasks complete or
fail. Worker thread itself might spun a few new threads for processing IO
Streams.
Depending on how much data it has to deal with, it can run from 4sec to
couple of hours. Of course nice UI with progress bars keeps user updated with
what's going on.
So far, it worked great for the user, I thought maybe I could put each
smaller tasks in ThreadPool, but now I don't think it would make that much of
a difference.
"Brian Gideon" wrote:

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.
My questions;

1. what's the difference?

The ThreadPool is managed by the framework. It is a fixed size pool of
threads that the framework uses to run work items asynchronously. It's
very easy to use. You simply make a call to
ThreadPool.QueueUserWorkItem and pass in a delegate of the method you
want to run.

2. Any performance benefits?

Yes, especially for work items that execute quickly. Since the threads
have already been created there is little overhead in getting a work
item to execute.

3. Can ThreadPool be used for the above-mentioned design pattern?

It depends. If the task you're wanting to run asynchronously takes a
long time to complete then no. You're better off managing your own
worker thread. If the task completes very quickly then it might be a
candidate. If you could explain what your existing worker thread does
then we could offer better advice.

If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.
Thank you

Like I said, generally tasks that complete quickly are candidates.

Thank you all,

From what I am hearing ThreadPool will not make my life easier in any form.
So far, I developed a few .NET applications, that automate certain production
tasks. Mostly has to do with pulling data from SQL Server and/or legacy file
server, processing it, and generating reports. So, I usually start a worker
thread that in turn makes calls to different objects that do all those
smaller tasks, worker thread raises events when certain tasks complete or
fail. Worker thread itself might spun a few new threads for processing IO
Streams.
Depending on how much data it has to deal with, it can run from 4sec to
couple of hours. Of course nice UI with progress bars keeps user updated with
what's going on.
So far, it worked great for the user, I thought maybe I could put each
smaller tasks in ThreadPool, but now I don't think it would make that much of
a difference.
"Brian Gideon" wrote:

Lenn wrote:

Hello,

I have always used a certain design pattern for multithreaded Windows app;
Start new worker thread from UI thread, use events to notify UI threads when
something happens, update UI controls using delegates through .BeginInvoke. I
came across some code samples recently where ThreadPool class is used to
start new threads.
My questions;

1. what's the difference?

The ThreadPool is managed by the framework. It is a fixed size pool of
threads that the framework uses to run work items asynchronously. It's
very easy to use. You simply make a call to
ThreadPool.QueueUserWorkItem and pass in a delegate of the method you
want to run.

2. Any performance benefits?

Yes, especially for work items that execute quickly. Since the threads
have already been created there is little overhead in getting a work
item to execute.

3. Can ThreadPool be used for the above-mentioned design pattern?

It depends. If the task you're wanting to run asynchronously takes a
long time to complete then no. You're better off managing your own
worker thread. If the task completes very quickly then it might be a
candidate. If you could explain what your existing worker thread does
then we could offer better advice.

If you could provide some insights on ThreadPool and specific instances when
ThreadPool should (or must) be used, I would greatly appreciate it.
Thank you

Like I said, generally tasks that complete quickly are candidates.