>> I share this opinion.
>> I would let the client sockets attached to a single the thread (no
>> necessarily the main thread) and handle all communication. 
>> Once a job has been received, then the data is passed to a worker thread,

>> thru a queue, for processing. Probably a single queue serviced by a pool
of thread is enough.
> What are your thoughts in having all communication in a single thread?

A single thread is able to handle the thruput of a FastEthernet connection
or - depending on the processor - even a GigabitEthernet. I mean if the
thread has only to handle the communication.

If significant processing or blocking processing has to be done, then it
must be delegated to a pool of threads. The ideal number of threads depends
on the kind of processing to be done. CPU bound processing will not benefit
from more thread than CPU core. As soon as there is I/O, the more thread are
required because some of them will be sleeping waiting for I/O.

> In my application we are starting to face some bottlenecks because all
processing of incomming data is received by the main thread, 

The main thread is busy with the user interface and this may slow down
communication considerably, depending on what happens on the user interface.

> what we did was to change the handle of some connections by detaching from
main thread 
> and attaching to another thread to process the messages. The connections
that we did 
> that are the ones that were causing the bottleneck.

Only one worker thread is enough as far as communication is concerned. For
processing, see above.

> So, my question is, in order to ICS to scale better in a multi-core
machine we should process the 
> incoming Windows messages in different threads (Of course, in a VERY WELL
> architecture to avoid deadlocks and conflicts) right?

Not exactly. IMO the best scalable architecture is to have a single thread
handling all communications (up to a certain network speed) and several
threads to handle a SUSTAINED gigabit network speed. Beside this
communication thread, processing has to be delegated to a thread pool
servicing a queue where the communication thread queue data to be processed.
Another queue keeps the flow the other way around.

Queues are very important because the avoid blocking a thread. Windows
message queue may be used for that purpose, or a queue you design yourself
(Or part of the VCL/RTL).

> Of course, in a VERY WELL designed  architecture to avoid deadlocks and

This is mandatory. And difficult to achieve. One of the bottle neck is
memory management. Avoid as much as possible dynamically allocated data. Use
pool for everything! One allocated, an object or memory block should stay
allocated. If not needed anymore, it has to be placed in a list where it
will be ready to be taken for a later processing/use.

Of course avoid Synchronize which actually defeat multithreading.

Embarcadero MVP

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to