线程池和短期线程 [英] thread pooling and short lived threads

问题描述

文档中的任何地方都有建议使用来自

线程池的线程来完成相对较短的任务。据我了解，从互联网上获取一个页面

或多页（有时多达50页但不是典型的）和

对这些页面进行一些处理将被认为是来自池的

a线程的大/长任务。在我们的应用程序中，可以将任务分解为一些

小的（每次获取和处理的线程或更小的事件），但

我们创建的线程越多越多我们得到的上下文切换

平衡点在哪里？我们对大/长任务会有什么处罚？


还有一件事。似乎存在大量异步

IO的错误，其中线程死锁和超时（它遍布开发人员

社区）。关于何时修复的任何信息？


谢谢，

阿列克谢

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 tipical) from the Internet and
doing some processing on those would be considered to be a big/long task for
a thread from a pool. In our app it is possible to break the task into some
small ones (thread per fetch and processing thereafter or event smaller), but
the more threads we create the more context switches we get. Where is the
ballance point? What penalties do we incur for big/long tasks?

One more thing. There seems to be a bug with large numbers of asynchronous
IO where threads deadlock and timeout (it is all over the developers
communities). Any info on when the fix is going to be out?

Thank you,

Alexei

推荐答案

你可能想要真正小心使用ThreadPool下载

使用WebRequest类的东西，因为他们也使用ThreadPool。我有很多

的痛苦来解决这个问题 - 不好玩！


-

Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram

" AlexeiOst" <铝******* @ discussions.microsoft.com>在消息中写道

新闻：79 ********************************** @ microsof t.com ...

You may want to be real careful about using the ThreadPool for downloading
stuff using WebRequest classes as they use the ThreadPool too. I had a lot
of pain figuring this out - not fun!

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram
"AlexeiOst" <Al*******@discussions.microsoft.com> wrote in message
news:79**********************************@microsof t.com...

文档中的任何地方都有建议使用来自线程池的线程来完成相对较短的任务。据我所知，从互联网上获取一个页面
或多页（有时多达50页但不是典型的）
和
对它们进行一些处理将被认为是大/长任务
来自池中的线程。在我们的应用程序中，可以将任务分解为一些小的（每次获取和处理的线程或更小的事件），
但是我们创建的线程越多越多我们得到的上下文切换
平衡点在哪里？我们对大/长任务会有什么处罚？

还有一件事。大量异步的IO似乎存在一个错误，其中线程死锁和超时（它遍布开发人员社区）。关于什么时候修复的消息？

谢谢你，

Alexei

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 tipical) from the Internet
and
doing some processing on those would be considered to be a big/long task
for
a thread from a pool. In our app it is possible to break the task into
some
small ones (thread per fetch and processing thereafter or event smaller),
but
the more threads we create the more context switches we get. Where is the
ballance point? What penalties do we incur for big/long tasks?

One more thing. There seems to be a bug with large numbers of asynchronous
IO where threads deadlock and timeout (it is all over the developers
communities). Any info on when the fix is going to be out?

Thank you,

Alexei

谢谢你的警告。不幸的是，我已经碰到了这个问题

已经如我在消息的另外一件事中提到的那样。或者是

还有其他你看过的东西吗？


谢谢，

Alexei


" Sriram Krishnan"写道：

Thank you for your warning. Unfortunatelly, I bumped into this problem
already as I mentioned in the ''One more thing'' part of the message. Or is
there something else that you saw?

Thank you,

Alexei

"Sriram Krishnan" wrote:

你可能想要真正小心使用ThreadPool下载使用WebRequest类的东西，因为他们也使用ThreadPool。我有很多痛苦来解决这个问题 - 不好玩！

-
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram

" AlexeiOst" <铝******* @ discussions.microsoft.com>在消息中写道
新闻：79 ********************************** @ microsof t.com。 ..

You may want to be real careful about using the ThreadPool for downloading
stuff using WebRequest classes as they use the ThreadPool too. I had a lot
of pain figuring this out - not fun!

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram
"AlexeiOst" <Al*******@discussions.microsoft.com> wrote in message
news:79**********************************@microsof t.com...

文档中的任何地方都有建议使用来自线程池的线程来完成相对较短的任务。据我所知，从互联网上获取一个页面
或多页（有时多达50页但不是典型的）
和
对它们进行一些处理将被认为是大/长任务
来自池中的线程。在我们的应用程序中，可以将任务分解为一些小的（每次获取和处理的线程或更小的事件），
但是我们创建的线程越多越多我们得到的上下文切换
平衡点在哪里？我们对大/长任务会有什么处罚？

还有一件事。大量异步的IO似乎存在一个错误，其中线程死锁和超时（它遍布开发人员社区）。关于什么时候修复的消息？

谢谢你，

Alexei

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 tipical) from the Internet
and
doing some processing on those would be considered to be a big/long task
for
a thread from a pool. In our app it is possible to break the task into
some
small ones (thread per fetch and processing thereafter or event smaller),
but
the more threads we create the more context switches we get. Where is the
ballance point? What penalties do we incur for big/long tasks?

One more thing. There seems to be a bug with large numbers of asynchronous
IO where threads deadlock and timeout (it is all over the developers
communities). Any info on when the fix is going to be out?

Thank you,

Alexei

不幸的是 - 你认为它是一个bug，而微软称这是''由
设计''。所以你被困住了我很害怕。您可以查看
http://www.bearcanyon.com / dotnet / #tpcontrol 有关如何使用
增加池线程限制的示例


-

Sriram Krishnan

http://www.dotnetjunkies.com/ weblog / sriram

" AlexeiOst" <铝******* @ discussions.microsoft.com>在消息中写道

新闻：3D ********************************** @ microsof t.com ...

Unfortunately - you consider it a bug while Microsoft says that is ''by
design''. So you''re stuck I''m afraid. You might want to check out
http://www.bearcanyon.com/dotnet/#tpcontrol for an example of how to
increase the pool thread limit

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram
"AlexeiOst" <Al*******@discussions.microsoft.com> wrote in message
news:3D**********************************@microsof t.com...

感谢您的警告。不幸的是，我已经碰到了这个问题，就像我在消息的另外一件事中所提到的那样。或者还有其他的东西你看到了吗？

谢谢你，

阿列克谢

Sriram Krishnan写道：

Thank you for your warning. Unfortunatelly, I bumped into this problem
already as I mentioned in the ''One more thing'' part of the message. Or is
there something else that you saw?

Thank you,

Alexei

"Sriram Krishnan" wrote:

你可能想要真正小心使用ThreadPool下载
使用WebRequest类的东西，因为他们也使用ThreadPool。我有很多痛苦来解决这个问题 - 不好玩！

-
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram

" AlexeiOst" <铝******* @ discussions.microsoft.com>在消息中写道
新闻：79 ********************************** @ microsof t.com。 ..

You may want to be real careful about using the ThreadPool for
downloading
stuff using WebRequest classes as they use the ThreadPool too. I had a
lot
of pain figuring this out - not fun!

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram
"AlexeiOst" <Al*******@discussions.microsoft.com> wrote in message
news:79**********************************@microsof t.com...

>文档中的任何地方都有使用线程的建议
>来自
>线程池用于相对较短的任务。据我所知，取一个
>页面
>
>或多页（有时最多50页，但不是典型的）互联网
>和
>对那些进行一些处理会被认为是一个很大/很长的
>任务
>对于
>来自池的线程。在我们的应用程序中，可以将任务分解为
>一些
>小的（每次获取和处理的线程或事件
>更小），
>但是
>我们创建的线程越多，我们得到的上下文切换就越多。
>
>平衡点？我们对大/长任务会受到什么处罚？
>
>还有一件事。似乎有大量的
>的错误。异步
> IO线程死锁和超时（它遍布开发人员
>社区）。有关何时修复的任何信息？
>
>谢谢，
>
>阿列克谢

> 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 tipical) from the
> Internet
> and
> doing some processing on those would be considered to be a big/long
> task
> for
> a thread from a pool. In our app it is possible to break the task into
> some
> small ones (thread per fetch and processing thereafter or event
> smaller),
> but
> the more threads we create the more context switches we get. Where is
> the
> ballance point? What penalties do we incur for big/long tasks?
>
> One more thing. There seems to be a bug with large numbers of
> asynchronous
> IO where threads deadlock and timeout (it is all over the developers
> communities). Any info on when the fix is going to be out?
>
> Thank you,
>
> Alexei

这篇关于线程池和短期线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！