Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.programming > #1285

Re: async I/O

Cross-posted to 2 groups.

Show all headers | View raw

In comp.unix.programmer Mark <mark_cruzNOTFORSPAM@hotmail.com> wrote:
> (I've faced quite a complex piece of software using asynchrounous messaging 
> and am having a tricky bug, which I believe is relevant to async I/O, so I'd 
> like to clarify some concepts).
> There are three processes, A,B and C, and A sends control messages to B & C 
> through a unix pipe. Now what happens is: process A sends a command to B, if 
> network link is not up, B sends command to C('link up') and C later confirms 
> to A that it's done, so B can change its state machine state. Also at some 
> moment process A sends 'link up' command to C. However state machine in B 
> never changes, although when I debug with GDB step-by-step, it functions 
> correctly (timings issue etc.?).

> Also, another observation - I set breakpoints in both processes B and C, 
> then execute A -- every time I start debug session, either B or C will be 
> the first to receive the message, so there is no guarantee that B or C is 
> always the first to get the message (I don't understand why).

> Is it possible that asynchronous messages don't deliver in order, e.g. A 
> first sends to B and then to C - can the B receive its message first and A 
> gets its message second (first or second in terms of timeline)?

I'm a bit puzzled what you mean by "asynchrounous messaging" and
"control messages" - my applogies if I miss the core of your pro-
blem completely. From what else you write I get the impression
that you have a number of pipes

A -> B
A -> C
B -> C
C -> A

Now, if you expect that when you write to the A->B pipe and
then to the A->C pipe that this would guarantee that B will
read on its pipe first before C reads on its then you're ma-
king wrong assumptions. The order in which processes are
scheduled to run by the operating system should be considered
to be completely random (and the processes A, B and C may even
run in parallel on machines with more than one processor!)

There is nothing that would ensure that process B will be run
before process C just because your process A first wrote to a
pipe to B and only then to a pipe to C. The operating system
schedules processes for running by a lot of different criteria
and you can never, ever rely on any certain order (well, un-
less you have read und understood the kernel sources in every
relevant detail and you are prepared to adjust your program
for every release of the kernel in existence;-)

So, if you want process B to read data from a pipe before
process C you must introduce some mechanism that makes sure
that this is what's going to happen. Just writing to a pipe
to B before writing to a pipe to C does not.

One way would be to have B send back an acknowledgment when it
has finished reading its data (e.g. via another pipe in the
opposite direction or a signal) and only then start sending
data to C. Only something like that can guarantee that C
won't start to read before B is done.

                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

Thread

async I/O "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-02-05 17:52 -0500
  Re: async I/O jt@toerring.de (Jens Thoms Toerring) - 2012-02-06 01:18 +0000
    Re: async I/O "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-02-05 22:43 -0500
  Re: async I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-06 00:38 -0500
  Re: async I/O scott@slp53.sl.home (Scott Lurndal) - 2012-02-06 16:11 +0000

csiph-web