启动一个新的Thread vs. ThreadPool [英] Starting a new Thread vs. ThreadPool
问题描述
您好，
我一直使用多线程Windows应用程序的某种设计模式;
从UI线程启动新的工作线程，使用事件通知UI线程在发生某些事情时，通过.BeginInvoke使用委托更新UI控件。我最近遇到了一些代码示例，其中ThreadPool类用于
开始新线程。
我的问题;
1.有什么区别？
2.任何性能优势？
3. ThreadPool可用于上述设计模式吗？
如果你能提供一些关于ThreadPool和特定实例的见解，那么
应该（或必须）使用ThreadPool，我将不胜感激。
谢谢
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
推荐答案
Lenn写道：
Lenn wrote:
你好，
我一直为多线程Windows应用程序使用某种设计模式;
从UI线程启动新的工作线程，当事情发生时使用事件通知UI线程，更新UI控件通过.BeginInvoke使用委托。我最近遇到了一些代码示例，其中ThreadPool类用于启动新线程。
我的问题;
1.有什么区别？
线程池中只有25个线程，排队执行的代码必须
等待终止池中正在运行的线程。
这意味着你可能会陷入饥饿状态，因为更新了
状态的线程因此终止了池中的线程终止他们可以继续无法运行:)
如果您已经启动了一个线程，那么您可能有1000个运行，并且当您尝试运行时会出现错误*开始*线程，而不是
僵局。
2.任何性能优势？
尝试一个分析器，如果你发现任何差异值得提交，请在这里发布。
提及。请记住（希望）少于你的代码的1％
产生线程，所以你只能获得很少的任何改进。
3.可以使用ThreadPool上述设计模式？
你已经*使用了线程池，其确切的方式是使用
：运行很快的代码片段终止。 .BeginInvoke
在线程池上执行队列。
如果你应该（或必须）使用ThreadPool，你可以提供一些关于ThreadPool和特定实例的见解，我非常感激。
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.
没有应该或必须使用的代码，让编译器
将它用于.BeginInvoke 。
不要将它用于你想要阻止的东西，等待其他
线程。
-
Helge Jensen
mailto：他********** @ slog.dk
sip：他** ********@slog.dk
- =>塞巴斯蒂安的封面音乐： http://ungdomshus.nu < = -
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写道：
Lenn wrote:
你好，
我一直使用某种设计模式对于多线程Windows应用程序;
从UI线程启动新的工作线程，当事情发生时使用事件通知UI线程，通过.BeginInvoke使用委托更新UI控件。我最近遇到了一些代码示例，其中ThreadPool类用于启动新线程。
我的问题;
1.有什么区别？
线程池中只有25个线程，排队执行的代码必须
等待终止池中正在运行的线程。
这意味着你可能会陷入饥饿状态，因为更新了
状态的线程因此终止了池中的线程终止他们可以继续无法运行:)
如果您已经启动了一个线程，那么您可能有1000个运行，并且当您尝试运行时会出现错误*开始*线程，而不是
僵局。
2.任何性能优势？
尝试一个分析器，如果你发现任何差异值得提交，请在这里发布。
提及。请记住（希望）少于你的代码的1％
产生线程，所以你只能获得很少的任何改进。
3.可以使用ThreadPool上述设计模式？
你已经*使用了线程池，其确切的方式是使用
：运行很快的代码片段终止。 .BeginInvoke
在线程池上执行队列。
如果你应该（或必须）使用ThreadPool，你可以提供一些关于ThreadPool和特定实例的见解，我非常感激。
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.
没有应该或必须使用的代码，让编译器
将它用于.BeginInvoke 。
不要将它用于你想要阻止的东西，等待其他
线程。
-
Helge Jensen
mailto：他********** @ slog.dk
sip：他** ********@slog.dk
- =>塞巴斯蒂安的封面音乐： http://ungdomshus.nu < = -
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写道：
Lenn wrote:
你好，
我一直使用某种设计模式来处理多线程Windows应用程序;
从UI线程启动新的工作线程，当事情发生时使用事件通知UI线程，通过.BeginInvoke使用委托更新UI控件。我最近遇到了一些代码示例，其中ThreadPool类用于启动新线程。
我的问题;
1.有什么区别？
ThreadPool由框架管理。它是一个固定大小的
线程池，框架用它来异步运行工作项。这是很容易使用的
。你只需打电话给
ThreadPool.QueueUserWorkItem并传入你想要运行的方法的委托。
2.任何表现好处是什么？
是的，特别是对于快速执行的工作项。由于已经创建了线程
，因此在执行工作时需要很少的开销
项目。
3.可以使用ThreadPool上述设计模式？
这取决于。如果您想要异步运行的任务需要很长时间才能完成，那么没有。你最好管理自己的
工作线程。如果任务很快完成，那么它可能是一个
候选人。如果你能解释你现有的工作线程是什么，那么我们可以提供更好的建议。
如果你能提供一些关于ThreadPool和特定实例的见解
ThreadPool应该（或必须）使用，我将不胜感激。
谢谢你
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.
这篇关于启动一个新的Thread vs. ThreadPool的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
