Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #493

Re: Non-deterministic behavior of multithreaded software

Show key headers only | View raw

On 05-08-2011 PM 07:50, Balog Pal wrote:
 > "itt ium" <ittium@gmail.com>
 >
 >> 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.
 >

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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