Thread Pool versus Dedicated Threads - Linux

This is a discussion on Thread Pool versus Dedicated Threads - Linux ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Thread Pool versus Dedicated Threads

  1. Thread Pool versus Dedicated Threads

    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**?

  2. Re: Thread Pool versus Dedicated Threads

    On Aug 13, 11:11 pm, ̉»Ê×Ê« wrote:

    > 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.

    > 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.

    > 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.

    > 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.)

    > 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

+ Reply to Thread