线程池与专用线程 [英] Thread Pool versus Dedicated Threads
问题描述
大家好，
最近我有一个新的同事。我们之间存在争议。
他工作的最后一家公司有一个特殊的网络编程
模型。他们将业务逻辑拆分为不同的模块，并为每个模块提供专用线程。模块通过内存消息队列交换信息
。
在我看来，这样的模型意味着非常复杂的异步
模块之间的互动。模块之间的简单函数调用
将需要一个计时器以避免永远等待答案。
如果一个模块被IO阻塞（如db查询），其他模块
取决于必须等待它。
例如，如果模块A想要查询db，它会
1.在列表中保存状态
2.向db-adapter模块发送消息（专用于db的线程
操作）
3.启动计时器
4.如果响应消息准时到达，请从
列表中检索状态，然后继续
5.如果计时器触发，记录错误信息并取消操作??
向用户发送错误通知??
我的新同事写了300,000这个模型中的代码行和
声称这是编写网络应用程序的最简单方法。
他说我们可以在半天内实现一个消息队列消息
会使界面更清晰。
我认为如果模块通过函数调用相互交互并且
a线程/进程池模型会更容易，其中每个
thread /
流程没有专门的工作，但处理任何主线程
给它。
但是因为我不喜欢在这个领域有很多经验，我不太确定。确定。
你怎么看待它？是否有任何成功的项目可以证明哪种型号**正确**？
Hi all,
Recently I had a new coworker. There is some dispute between us.
The last company he worked for has a special networking programming
model. They split the business logic into different modules, and have
a dedicated thread for the each module. Modules exchanged info
through a in-memory message queue.
In my opinion, such a model means very complicated asynchronous
interaction between module. A simple function call between modules
would require a timer to avoid waiting for answer forever.
And if a module was blocked by IO (such as db query), other modules
depends on would have to wait for it.
For example, if module A want to query db, it would
1. save states in a list
2 .sending a message to db-adapter module (a thread dedicated for db
operation)
3. start a timer
4. if response message arrived on time, retrieve states from the
list, and go on
5. if timer fires, log an error message and cancel the operation ??
send an error notify to user??
My new coworker had written 300,000 lines of code in this model and
claimed this is the most simple way to write a network application.
He said we could implement a message queue in half-a day and message
would make interface much more clear.
I think if module interact with each other through function calls and
a thread/process pool model would be more easier, in which each
thread/
process has no dedicated job but handle whatever the master thread
give it.
But as I don''t have much experience in this area, I am not quite
sure.
What do u think about it? Is there any successful projects that could
prove which model is **right**?
推荐答案
???é |？è？写道：
???é|?èˉ? wrote:
大家好，
Hi all,
< snip>
有趣的是，那里并没有真正的C ++问题。你将获得更多关于comp.programming.threads的见解。
-
Ian Collins。
<snip>
While interesting, there isn''t really a C++ question in there. You
would get more insight on comp.programming.threads.
--
Ian Collins.
8月14日上午8:20，??? < newpt ... @ gmail.comwrote：
On Aug 14, 8:20 am, ??? <newpt...@gmail.comwrote:
最近我有一个新的同事。我们之间存在争议。
Recently I had a new coworker. There is some dispute between us.
他工作的最后一家公司有一个特殊的网络
编程模型。他们将业务逻辑拆分为
不同的模块，并为每个
模块提供专用线程。模块通过内存消息交换信息
队列。
The last company he worked for has a special networking
programming model. They split the business logic into
different modules, and have a dedicated thread for the each
module. Modules exchanged info through a in-memory message
queue.
在我看来，这样的模型意味着模块之间的异步交互非常复杂。
In my opinion, such a model means very complicated
asynchronous interaction between module.
如果有共同的数据，模块之间总会有或多或少的
复杂的异步交互。
专用线程模型通常会减少公共数据。到
只是消息队列，这让事情变得更加简单。
If there''s common data, there''s always a more or less
complicated asynchronous interaction between modules. The
dedicated thread model normally reduces the "common data" to
just the message queue, which makes things significantly
simpler.
模块之间的简单函数调用需要一个计时器
以避免永远等待答案。如果一个模块被IO阻止了
（例如数据库查询），其他模块依赖于
必须等待它。
A simple function call between modules would require a timer
to avoid waiting for answer forever. And if a module was
blocked by IO (such as db query), other modules depends on
would have to wait for it.
是的。这是不利的一面。单个专用线程（或者可以是
）是一个瓶颈。当然，无论如何都会出现这样的瓶颈
;如果你操纵一个共享资源，例如，需要锁定的
。
Yup. That''s the downside. The single, dedicated thread is (or
can be) a bottleneck. Of course, such bottlenecks can occur
anyway; if your manipulating a shared resource, for example,
which needs locking.
例如，如果模块A想要查询db，那么将
For example, if module A want to query db, it would
1.在列表中保存状态
2.向db-adapter模块发送消息（专用线程）对于db
操作）
3.启动计时器
4.如果响应消息准时到达，则从
检索状态
列表，并继续
5.如果计时器触发，记录错误消息并取消操作??
向用户发送错误通知？
1. save states in a list
2 .sending a message to db-adapter module (a thread dedicated for db
operation)
3. start a timer
4. if response message arrived on time, retrieve states from the
list, and go on
5. if timer fires, log an error message and cancel the operation ??
send an error notify to user??
我将超时时间放在数据库适配器模块中。除此之外：
将请求放入单个
块并将其发布到消息队列并传递
$之间的区别是什么？ b $ b信息作为函数的参数？
I''d put the time-out in the DB adapter module. Other than this:
what''s the difference between putting the request in a single
block and posting it to the message queue, and passing the
information as arguments to a function?
我的新同事在这个
模型中编写了300,000行代码并声称这是编写
网络应用程序的最简单方法。他说我们可以在半天内实现一条消息
队列，并且消息可以使接口更加清晰
清除。
My new coworker had written 300,000 lines of code in this
model and claimed this is the most simple way to write a
network application. He said we could implement a message
queue in half-a day and message would make interface much more
clear.
使用消息
队列来获取代码通常更容易，但它不是灵丹妙药。你仍然可以得到
的死锁。但是由于两个线程访问相同的数据而没有足够的
同步，因此你不太可能遇到问题。
It''s typically easier to get the code right using the message
queue, but it''s not a silver bullet. You can still end up with
deadlocks. But you''re much less likely to have problems due to
two threads accessing the same data without sufficient
synchronization.
我认为如果模块通过函数相互交互
调用和一个线程/进程池模型会更容易，在每个线程/进程中每个线程/进程没有专门的工作，但处理
无论主线程给它。
I think if module interact with each other through function
calls and a thread/process pool model would be more easier, in
which each thread/ process has no dedicated job but handle
whatever the master thread give it.
线程/进程池模型什么都不是。我不是确定你提出的真正替代方案。大多数地方我已经使用每个客户端连接的线程工作了
;在收到
请求时，线程会抓取它需要的任何锁定并且
完成工作，或将其转发到专用线程（
然后不需要任何锁，因为它是
访问信息的唯一线程）。两种模式都有效。哪一个是
更好取决于应用程序。
-
James Kanze（GABI软件）电子邮件：ja ** *******@gmail.com
Conseils eninformatiqueorientéeobjet/
Beratung in objektorientierter Datenverarbeitung
9placeSémard，78210 St.-Cyr-l''école，法国，+ 33（0）1 30 23 00 34
A "thread/process pool model" doesn''t mean anything. I''m not
sure what real alternative you''re suggesting. Most places I''ve
worked at use a thread per client connection; on receiving a
request, the thread either grabs whatever locks it needs and
does the work, or forwards it to the dedicated thread (which
then doesn''t need any locks, because it is the only thread which
accesses the information). Both models work. Which one is
better depends on the application.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l''école, France, +33 (0)1 30 23 00 34
" James Kanze" < ja ********* @ gmail.comwrote：
"James Kanze" <ja*********@gmail.comwrote:
A" thread / process pool model"什么都不是。我不确定你提出的真正替代方案。
A "thread/process pool model" doesn''t mean anything. I''m not
sure what real alternative you''re suggesting.
真正的替代方法是创建类似的消息队列设计，但完全打破客户端与线程的连接关系。客户端连接存在于通信库的可扩展性所需的尽可能多的线程中。进入的请求被打包并发布到消息队列。
工作线程池，与服务器中的虚拟CPU数量成比例（而不是客户端连接数）从队列中提取请求处理请求，然后返回查看队列中是否有任何要处理的内容。
这种设计最终可以更好地调整以保持CPU内核的繁忙程度可能的，同时最小化不必要的上下文切换，使其具有活动状态。线程数远远超过CPU可用性。给定数据库服务器同样可以使用异步文件io一次处理多个请求，这种设计将使数据库保持繁忙，而不是连续地在单个DB对象中进行瓶颈。线程。
The real alternative is to create a similar message queue design, but completely break the relationship of client connections to threads. Client connections exist on as many or as few threads as needed by the scalibility of the comms library. Requests coming in are packaged and posted to a message queue.
A pool of worker threads, proportional to the number of virtual CPUs in the server (rather than the number of client connections) pull requests from the queue, process the request, and then go back to see if theres anything in the queue to process.
This sort of design can ultimately be far better tuned to keep the CPU cores as busy as possible, while minimising needless context switches from having an "active" thread count far in excess of CPU availability. Given a database server that can, likewise, process multiple requests at once using asynchronous file io, this design will keep the database busy, rather than continually bottlenecking in the single DB "object" thread.
这篇关于线程池与专用线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
