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

Groups > comp.programming.threads > #492

Re: Non-deterministic behavior of multithreaded software

Show all headers | 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