Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: ittium Newsgroups: comp.programming.threads Subject: Re: Non-deterministic behavior of multithreaded software Date: Tue, 09 Aug 2011 08:52:34 +0530 Organization: A noiseless patient Spider Lines: 51 Message-ID: <4E40A7FA.8080800@gmail.com> References: <0dddaf2a-95be-4423-9420-3d4c8bf8c013@y8g2000prd.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="Jr+GCtWa+XbvmSdRpa1MLQ"; logging-data="18376"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ckEwypwvyPd0KVc5EKA+V" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: Cancel-Lock: sha1:kkHDcGgZdSBaqvoYYJcD4p9loy4= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:493 On 05-08-2011 PM 07:50, Balog Pal wrote: > "itt ium" > >> I have recently modified a software from single threaded to >> multithreaded design. In single threaded version, a connection fd was >> read by single thread, so event were always delivered in order. Now >> since multiple threads handle different events (on the same fd), the >> events are sometimes delivered out of order. > > You mean processed. Yes, There is another module that receives the processed data and that data is delivered to the module out of order. > >> Please note, on the >> connection fd, events are received in proper order and this non- >> deterministic behavior is introduced by my software only. >> >> 1. How to handle such a situation > > Go back one square, to your single-threaded design. And only start > threading when you know to what end. We want to increase the message processing capacity per second for the software.with a single threaded design, we have reached the maximum capacity (in terms of message processed per second). Please note we are running the software on a hexacore machine. > >> 2. Is it a bad idea to have multiple threads for the same fd. If yes >> than how to increase capacity of a software that receives large amount >> of data on a single fd only. > > In what you write I see little relevance of the fd. You need processing > of the events one after the other, waiting to start the next until the > previous finishes, right? So you shall not try to run them in parallel. > And a single thread does just that. (If your problem is not like that, > state it clearly.) > > If reading the fd is really a concern, then you can put that in one > thread and processing in another. So you have a simplest 1-1 1-1 is not likely a solution, it will only introduce unnecessary context switch. In our solution, there are multiple worker threads, each can read from fd, when fd is ready. > producer-consumer queue, one thread rads and posts to the queu, the > other processes the events in the queue. If the source of events is > independent, you will have the reading in parallel. >