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?
2. Any performance benefits?
3. Can ThreadPool be used for the above-mentioned design pattern?
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 10 8726
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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: AlexeiOst |
last post by:
Everywhere in documentation there are recommendations to use threads from
thread pooling for relatively short tasks. As I understand, fetching a page
or multiple pages (sometimes up to 50 but not...
|
by: serge calderara |
last post by:
Dear all,
I have an application which is suppose to start another executable process.
As soon as that process is running, I need to retrive its handle. The
problem of the particular process I am...
|
by: objectref |
last post by:
hi to all folks,
i want to create the following senario:
i have a T1 (Thread 1) that acts like http server that receives incoming
requests.
From that T1, i want to spawn from T1 to Tn thread...
|
by: Lenn |
last post by:
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...
|
by: trint |
last post by:
Ok,
I start my thread job:
Thread t = new Thread(new
ThreadStart(invoicePrintingLongRunningCodeThread));
t.IsBackground = true;
t.Start();
There are lots of calls to controls and many...
|
by: Andrew Bullock |
last post by:
Hi,
code:
myClass x = new myClass();
x.dosomethingwith(x,y);
How do i make dosomethingwith(x,y) run on a separate thread, and then
inform the main thread when it has finished?
|
by: Sin Jeong-hun |
last post by:
Hi. I'm writing a Client/Multi-threaded Server program on Windows
Vista. It worked fine on Windows Vista, but when the server ran on
Windows XP,
I/O operation has been aborted because of either...
|
by: Creativ |
last post by:
Why does Thread class not support IDisposable? It's creating quite
some problem. Namely, it can exhaust the resource and you have not
control over it.
|
by: Curious |
last post by:
On Jun 10, 3:32 am, <s...@dailycoding.comwrote:
Thanks! I'll use thread pool.
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |