Tracing problem. Lock()

  • Thread starter Thread starter Claire
  • Start date Start date
C

Claire

My application runs for a while then just stops completely. No stack
overflows or any other errors, visual studio doesn't report any problems. I
can close the application down ok from the studio toolbar. If I check Task
Manager, CPU is 0%, memory changes a little over time.
I constantly log application flow to the output pane. Logging stops, usually
only a portion of the "current" debug string is displayed ie the thread
that's writing to the output pane is just stopping too.
There's several threads, originating from system.thread.timer objects.
Variables that are shared across threads are protected by Lock().

I wondered if this is a problem caused by locks, so to test I added
"entering lock", "locked", "unlocked" around every Lock(){} call.
I'm having trouble debugging this. Are there any tools out there that can
tell the state of locked threads?

thanks
 
Claire said:
My application runs for a while then just stops completely. No stack
overflows or any other errors, visual studio doesn't report any problems. I
Click to expand...

You do know you can break it in the debugger (or attach to it) and
inspect each threads state, callstack, ...
 
If I break in, it stops on the "Application.Run(form1);" line
In a multithreaded application (3 main threads plus other threads entering
at the end of timer timeout period) why would every thread stop concurrently
like that?
I could understand 2 threads competing for a lock but the remainder should
continue shouldn't they?
 
Claire said:
If I break in, it stops on the "Application.Run(form1);" line
In a multithreaded application (3 main threads plus other threads entering
at the end of timer timeout period) why would every thread stop concurrently
like that?
Click to expand...

Inspect the call-stack of *all* the threads.

If all your other threads are waiting for timers, then nothing is going
to happen untill a timer fires, or some windows message is sent to your
form.

The main thread is probably stuck in Application.Run since no windows
messages are being passed to your form at the moment you break.
I could understand 2 threads competing for a lock but the remainder should
continue shouldn't they?
Click to expand...

If they are waiting for a timer to elapse, they *are* running.

If the threads we awaiting a "lock" I would expect to see that at some
point in their call-stacks.

Event-driven programs doesn't "run" untill there is an event to react
to. If nobody generates any events -- nothing happens.

BTW: It's hard to generate GUI-event while running in the debugger. You
can make a button that does something and set a breakpoint in the
handler for it.
 
u can view running threads state. Press ctrl+alt+H or ctrl+shift+H. i dont
remeber which one.
 
Back
Top