| |
 |
|
|
Linux Forum Index » Linux Development - Applications » Thread Pool versus Dedicated Threads...
Page 1 of 1
|
| Author |
Message |
| 一首诗... |
 Posted: Wed Aug 13, 2008 8:11 pm |
|
|
|
Guest
|
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**? |
|
|
| Back to top |
|
| David Schwartz... |
| Posted: Wed Aug 13, 2008 8:27 pm |
|
|
|
Guest
|
On Aug 13, 11:11 pm, 一首诗 <newpt... at (no spam) gmail.com> wrote:
Quote: 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.
This is generally a sub-optimal model unless there's some unusual
reason why dedicating a thread to a module makes sense. It means that
if an operation has to pass through 10 modules, 10 different threads
have to touch it. It also means that the number of threads cannot be
adjusted to optimize performance but is dictated by the number of
modules.
That said, if it is easier to implement (and in some cases it is) or
if it eliminates a lot of lock interaction (since only one thread can
be in a module at a time), but may be the best overall choice. This
is, however, rare.
There is no reason thread A should hand a message to thread B and wait
for thread B to process it if thread A, which already has the message,
can just process it itself.
On the flipside, of the processing code is large, it may be better to
have one thread process a large number of messages, keeping the
processing code in the CPU cache.
Quote: 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.
Right, which means you lose a lot of the benefits of threading. You
don't want threads to 'line up' behind an I/O operation. You'd rather
completion of the I/O operation automatically trigger the processing.
Ideally, it would be processed in the thread that completed the I/O
operation, but nearly as good is if the thread that completes the I/O
operation queues a job.
Quote: 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......
The net result is you now have at least two threads stuck waiting for
the operation to complete. Any other jobs that need to use either of
those two modules will get stuck behind those two threads. One
expensive operation can slow down the whole server. You lose much of
the benefits of threads this way.
Quote: 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 personally have found that sending messages between threads is
almost never useful. Why send data from thread A to thread B when
thread A already has the data? What can thread B do that thread A
can't? (If there is something, then you have your answer. But if
there's no answer to that question, the design is sub-optimal.)
Quote: 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.
You don't need or want a master thread. You want a thread to be able
to go from doing one job to doing another job without any context
switches. You may need a master thread to handle timers or wait for I/
O, but you should not need a master thread to tell other threads what
do to.
The logic should simply be -- take the head job off the job queue. If
no job, block on the job queue.
DS |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Fri Nov 21, 2008 8:41 pm
|
|