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

Groups > comp.programming.threads > #494

Re: Non-deterministic behavior of multithreaded software

Show key headers only | View raw

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

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