Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #494
| From | ittium <ittium@gmail.com> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | Re: Non-deterministic behavior of multithreaded software |
| Date | 2011-08-09 09:19 +0530 |
| Organization | A noiseless patient Spider |
| Message-ID | <4E40AE63.2050804@gmail.com> (permalink) |
| References | <0dddaf2a-95be-4423-9420-3d4c8bf8c013@y8g2000prd.googlegroups.com> <0.3b106e5acd52269bad7d.20110805161719BST.87sjpfx4zk.fsf@bsb.me.uk> |
On 05-08-2011 PM 08:47, Ben Bacarisse wrote: > itt ium<ittium@gmail.com> 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.
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Non-deterministic behavior of multithreaded software itt ium <ittium@gmail.com> - 2011-08-05 02:42 -0700
Re: Non-deterministic behavior of multithreaded software "Balog Pal" <pasa@lib.hu> - 2011-08-05 16:20 +0200
Re: Non-deterministic behavior of multithreaded software ittium <ittium@gmail.com> - 2011-08-09 08:49 +0530
Re: Non-deterministic behavior of multithreaded software ittium <ittium@gmail.com> - 2011-08-09 08:52 +0530
Re: Non-deterministic behavior of multithreaded software Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-05 16:17 +0100
Re: Non-deterministic behavior of multithreaded software ittium <ittium@gmail.com> - 2011-08-09 09:19 +0530
Re: Non-deterministic behavior of multithreaded software Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-09 14:08 +0100
Re: Non-deterministic behavior of multithreaded software David Schwartz <davids@webmaster.com> - 2011-08-10 12:37 -0700
csiph-web