Hello everybody,

I have a question about how things are executed (I do realize it's up
to the scheduler in the OS, in this case Linux, Red Hat 9) in
multi-threaded apps and such.

I have an application where I'm dumping > 16mb of data on to a file
descriptor and the network interface card (using the socket()
connect() and send() calls), that is 16mb on both, total of > 32mb.

I have written two different versions of the program because I was
concerned that my first attempt at writing multi-threaded apps wasn't
doing what I thought it was.  In the first, the multi-threaded
version, main() opens a thread that writes the data on to the network,
and main() dumps the data to /dev/lp0.

In the other version, I use fork() to create a child that does the
network stuff while the parent does the /dev/lp0 stuff.  I've written
some basic status stuff in to the program, by basic I mean that at
intervals some status strings are printed to stdout in the form of
fprintf(stdout, "child/thread still kicking").

The deal is though, I don't think that the execution is happening in
paralle in either case.  For instance, when either is run, all the
child/thread1 stuff is printed to stdout first, then the
parent/thread0 stuff after that.  I would have expected that the
programs would be executing in a parallel manner.  Parent/thread0 for
a while, child/thread1 for a while, parent/thread0 for a while, ...
etc.

Any suggestions?

Andy

[ Post a follow-up to this message ]

Perhaps I/O operations tend to want to run til completion, and not share
the cpu, unless the operation is VERY long.

Andrew Falanga wrote:
quote:

> Hello everybody,
>
> I have a question about how things are executed (I do realize it's up
> to the scheduler in the OS, in this case Linux, Red Hat 9) in
> multi-threaded apps and such.
>
> I have an application where I'm dumping > 16mb of data on to a file
> descriptor and the network interface card (using the socket()
> connect() and send() calls), that is 16mb on both, total of > 32mb.
>
> I have written two different versions of the program because I was
> concerned that my first attempt at writing multi-threaded apps wasn't
> doing what I thought it was.  In the first, the multi-threaded
> version, main() opens a thread that writes the data on to the network,
> and main() dumps the data to /dev/lp0.
>
> In the other version, I use fork() to create a child that does the
> network stuff while the parent does the /dev/lp0 stuff.  I've written
> some basic status stuff in to the program, by basic I mean that at
> intervals some status strings are printed to stdout in the form of
> fprintf(stdout, "child/thread still kicking").
>
> The deal is though, I don't think that the execution is happening in
> paralle in either case.  For instance, when either is run, all the
> child/thread1 stuff is printed to stdout first, then the
> parent/thread0 stuff after that.  I would have expected that the
> programs would be executing in a parallel manner.  Parent/thread0 for
> a while, child/thread1 for a while, parent/thread0 for a while, ...
> etc.
>
> Any suggestions?
>
> Andy

[ Post a follow-up to this message ]

You might want to verify that this is not an oddity of behaviour caused
by both threads/processes dumping to stdout/stderr on your controlling
terminal?  Try sending the status info to two different files?  Also,
How quickly is 16M written?  i.e. can 16M be written before a the new
thread/process has a chance to get up and running?  Try the same test
with 100's of MBytes and see if the contect swtiching is more apparent.

In a 100 Mb/s network connection, you may be able to dump 10 MBytes/s.

Cheers.

Andrew Falanga wrote:
quote:

> Hello everybody,
>
> I have a question about how things are executed (I do realize it's up
> to the scheduler in the OS, in this case Linux, Red Hat 9) in
> multi-threaded apps and such.
>
> I have an application where I'm dumping > 16mb of data on to a file
> descriptor and the network interface card (using the socket()
> connect() and send() calls), that is 16mb on both, total of > 32mb.
>
> I have written two different versions of the program because I was
> concerned that my first attempt at writing multi-threaded apps wasn't
> doing what I thought it was.  In the first, the multi-threaded
> version, main() opens a thread that writes the data on to the network,
> and main() dumps the data to /dev/lp0.
>
> In the other version, I use fork() to create a child that does the
> network stuff while the parent does the /dev/lp0 stuff.  I've written
> some basic status stuff in to the program, by basic I mean that at
> intervals some status strings are printed to stdout in the form of
> fprintf(stdout, "child/thread still kicking").
>
> The deal is though, I don't think that the execution is happening in
> paralle in either case.  For instance, when either is run, all the
> child/thread1 stuff is printed to stdout first, then the
> parent/thread0 stuff after that.  I would have expected that the
> programs would be executing in a parallel manner.  Parent/thread0 for
> a while, child/thread1 for a while, parent/thread0 for a while, ...
> etc.
>
> Any suggestions?
>
> Andy


--
 ========================================
================================
Missaka Wijekoon (a.k.a. Misk)
Sr. Software Engineer
mwijekoon@villageEdocs.RemoveToSend.com

VillageEdocs
http://www.villageEdocs.com
 ========================================
================================

[ Post a follow-up to this message ]

"Andrew Falanga" <afalanga@syracusenetworks.com> wrote in message
news:ab2edd3a.0312090636.3cab558f@posting.google.com...
quote:

> fprintf(stdout, "child/thread still kicking").

[snip..]
quote:

> The deal is though, I don't think that the execution is happening in
> paralle in either case.  For instance, when either is run, all the
> child/thread1 stuff is printed to stdout first, then the
> parent/thread0 stuff after that.  I would have expected that the


Maybe use fprintf(stderr,"child/thread still kicking"), note the "stderr"
instead of "stdout", since stderr is unbuffered and will write immediately.

Regards,

Mike Chirico

[ Post a follow-up to this message ]