Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Debugging Multithreaded and Realtime Application on WIndows

1 view
Skip to first unread message

Panks

unread,
Sep 27, 2006, 4:17:54 PM9/27/06
to
HI Guys

I need some help with debugging a multithreaded application. It has
currentily 500 Concurrent threads running. When i try debugging in VC++
IDE with all threads my system crashes. I am new to multithreading. Can
some one give me idea how to develop a debugger module or any built in
tool to debug my application.


Thanks
Pankaj

Jerry Coffin

unread,
Sep 28, 2006, 1:18:24 AM9/28/06
to
In article <1159388274.7...@e3g2000cwe.googlegroups.com>,
pank...@yahoo.co.in says...

First of all, I'd advise re-designing your application -- I have a
difficult time imagining a circumstance under which 500 threads even
begins to make real sense (at least at the present time -- on Intel's
promised 80-core processor, it might start to make more sense).

My immediate guess is that somewhere inside of the debugger, it'd doing
something like a WaitForMultipleObjects, which is limited to waiting on
64 handles at a time, and it's just not planning for having 500 threads.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Panks

unread,
Oct 3, 2006, 2:03:40 PM10/3/06
to
Hi Jerry

Thanks for comment. let me tell ya abt scenario in my project. Here
each thread represent an object (Trading symbol) montioring activity of
market realtime. These are hyper active entities any delay due to
queuing or any subclassificatiuon in threads may disrupt the buisness
logice. Hence bunching them will degrade buisness logic implementation
and my users performance expectation.

Pankaj

Jerry Coffin

unread,
Jan 23, 2007, 10:54:47 PM1/23/07
to
In article <1159898620....@b28g2000cwb.googlegroups.com>,
pank...@yahoo.co.in says...

> Hi Jerry
>
> Thanks for comment. let me tell ya abt scenario in my project. Here
> each thread represent an object (Trading symbol) montioring activity of
> market realtime. These are hyper active entities any delay due to
> queuing or any subclassificatiuon in threads may disrupt the buisness
> logice. Hence bunching them will degrade buisness logic implementation
> and my users performance expectation.

In case you're still around: not really. In a typical situation, you'll
be processing data coming in a network port -- that means you have a
single stream of data that can entirely reasonably be processed by a
single thread.

Spawning 500 threads is not going to ensure that the data is processed
faster -- rather the contrary, it's going to add enough overhead that it
nearly ensures that the data will be processed more slowly. What you
need is simply enough threads to assure that the processor has something
to do at any given time. Beyond that, adding more threads slows things
down rather than speeding them up.

0 new messages