>> 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 designed > 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 conflicts 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. -- francois.pie...@overbyte.be Embarcadero MVP http://www.overbyte.be http://francois-piette.blogspot.com -- 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
