Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #1060
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.unix.programmer |
| Subject | Re: Non-deterministic behavior of multithreaded software |
| Date | 2011-08-05 15:41 +0100 |
| Message-ID | <87hb5vyl8a.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | <717d47a8-8f8b-4fdd-8331-e9119c941f77@j14g2000prn.googlegroups.com> |
itt ium <ittium@gmail.com> writes: > 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 If you need such an ordering and it isn't implicitly guaranteed anymore because it is now possible to work an several requests in parallel, the intended order needs to be restored after the parts of the task which are parallelizable have completed. A simple idea how this could be done would be to include a 'ticket number' in the request that can later be used to determine the ordering which was lost in between again. > 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. 'Multiple threads' can only be of help if at least some parts of the work some program is supposed to do can be performed indepedently of each other in parallell. Otherwise, if you cannot used more than one CPU/ 'execution unit' and need to increase the capacity, you need to get a faster execution unit or reduce the resource-intensity of request processing so that the same 'execution unit' can process more requests during some time interval.
Back to comp.unix.programmer | 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:38 -0700
Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-05 15:41 +0100
Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-05 14:46 -0700
Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-05 23:04 +0100
Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-05 18:54 -0700
Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-06 14:59 +0100
Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-06 20:29 -0700
Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-07 20:02 +0100
Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-07 18:09 -0700
Re: Non-deterministic behavior of multithreaded software ittium <ittium@gmail.com> - 2011-08-09 09:48 +0530
csiph-web