Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!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 09:19:55 +0530 Organization: A noiseless patient Spider Lines: 71 Message-ID: <4E40AE63.2050804@gmail.com> References: <0dddaf2a-95be-4423-9420-3d4c8bf8c013@y8g2000prd.googlegroups.com> <0.3b106e5acd52269bad7d.20110805161719BST.87sjpfx4zk.fsf@bsb.me.uk> 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="25606"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LIEhP6pSyPuz6IHx5gi4O" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <0.3b106e5acd52269bad7d.20110805161719BST.87sjpfx4zk.fsf@bsb.me.uk> Cancel-Lock: sha1:moslLp8KLaMMJPpA5P13ox2fuas= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:494 On 05-08-2011 PM 08:47, Ben Bacarisse wrote: > itt ium writes: > >> Group, >> 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. Please note, on the >> connection fd, events are received in proper order and this non- >> deterministic behavior is introduced by my software only. >> >> Following are my doubt >> >> 1. How to handle such a situation > > That's nothing less than one of the basic questions of concurrent > programming -- how to ensure that actions occur in only one of the > (possibly many) permitted orders and never in any of the prohibited > orders. It's too general a question to be answered here. > I appreciate your thought on it. But I was thinking of getting the help from experts so that I am not reinventing the wheel. I have done sufficient googling before posting it. Closest solution, is studying the software using concurrent sequential processing grammar (CSP). It will take sometime for me to learn the grammar. >> 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. > > It can be a bad idea but it can also be a perfectly sound one. Because > you are not sure I suspect you have a case where it is a bad idea, but I > can't be certain of that. The key is probably this: if a thread can > determine what it needs to know in order to schedule its actions with > respect to the other threads by looking at the data it reads (and maybe, > in addition, consulting a little shared data too) then having multiple > readers is probably fine. If the threads can't do this, or they would > need to cooperate in maintaining a lot of shared data in order to do > this, then you are probably better off with one reader which organises > the work of the others. > There are few more inputs here. My software is handing the call session. The problem occur, if event for a call are delivered out of order. I have modified the software such that message belonging to a call are processed by same thread, in this way ordering of events for the call state machine is maintained. But this has introduced a pinner thread that assign the messages to different worker threads based on a a hash function that take input as call ID. 1. Thread ID may not be uniformly distributed, any logic of work devision might load few thread. 2. A context switch is introduced because of pinner. Earlier a single thread was doing all the work (from reading from socket to delivering it to other modules. >> Because of the relevance I am posting the message to following groups. >> >> comp.unix.programmer >> comp.programming.threads > > That's a bad idea. Cross posting is generally referred to multi-posting. > thanks for pointing this out. I was thinking, some of the members of comp.unix.programmer might have worked on message processing systems and can help me.