System.Threading.Thread.Suspend/Resume and StackTrace

On Tue, 12 Jun 2007 22:25:00 -0700, Mark Channing <Mark
<Ch******@discussions.microsoft.com>wrote:

[...]
However under .NET 2.0 System.Threading.Thread.Suspend/Resume have been
marked as obsolete with reference to better methods of synchronisation.
I
agree with the comment about synchronisation however I am not trying to
sychonise threads, I just need the thread in an ok state to run the
Stacktrace method.

Any suggestions to how this should be achieved.

Just use Suspend() and Resume(). They are still necessary in certain
cases, and your situation would be one of them. No, they are not the
right way to deal with thread synchronization issues, but if you can't get
the stack trace of a thread without suspending it, then you need to
suspend it if you want to get the stack trace (seems obvious, no? :) ).

Sounds like you're doing a sampling profiler? :)

Pete

Thanks for you response. I have no issues with using Suspend Resume methods.
However when reading the link that comes with the build warning, obsolete,
may be removed in future releases then I supposed there must be another way.

The code is some in application that I have moved onto and was added to trap
deadlocks. If GUI thread was running user can invoke thread dumper to output
all threads to find where some non GUI thread was locked. Alternatively if
GUI was locking regularly we could enable a timer thread to dump threads at
certain intervals. Personally I am not keen on either approach and would
expect some external tool that could do a core dump would be a better
approach.

"Peter Duniho" wrote:

On Tue, 12 Jun 2007 22:25:00 -0700, Mark Channing <Mark
<Ch******@discussions.microsoft.com>wrote:

[...]
However under .NET 2.0 System.Threading.Thread.Suspend/Resume have been
marked as obsolete with reference to better methods of synchronisation.
I
agree with the comment about synchronisation however I am not trying to
sychonise threads, I just need the thread in an ok state to run the
Stacktrace method.

Any suggestions to how this should be achieved.

Just use Suspend() and Resume(). They are still necessary in certain
cases, and your situation would be one of them. No, they are not the
right way to deal with thread synchronization issues, but if you can't get
the stack trace of a thread without suspending it, then you need to
suspend it if you want to get the stack trace (seems obvious, no? :) ).

Sounds like you're doing a sampling profiler? :)

Pete

On Wed, 13 Jun 2007 01:28:00 -0700, Mark Channing
<Ma**********@discussions.microsoft.comwrote:

Thanks for you response. I have no issues with using Suspend Resume
methods.
However when reading the link that comes with the build warning,
obsolete,
may be removed in future releases then I supposed there must be another
way.

I suppose that's a theoretical possibility. But I'd be very surprised if
Suspend() and Resume() were ever removed. Windows is chock full of
"obsolete" APIs, some dating way back to the earliest days of the OS.
This is in fact one great thing about Windows and perhaps its biggest
Achilles heel: Microsoft invests significant resources in ensuring that
legacy applications still work as the OS evolves.

I can't guarantee you that the methods won't be removed, but it would sure
surprise me if they were. At the very minimum, long before they are
completely unavailable to any application you won't be able to compile new
code using them.

Also...

The code is some in application that I have moved onto and was added to
trap
deadlocks. If GUI thread was running user can invoke thread dumper to
output
all threads to find where some non GUI thread was locked.

This sounds to me as though it's a temporary diagnostic sort of thing. A
multi-threaded application should not have deadlocking code, and in the
long-term the goal should be to simply have correctly written code that
doesn't deadlock in the first place. Even more reason to not worry about
the long-term viability of Suspend() and Resume().

[...] Personally I am not keen on either approach and would
expect some external tool that could do a core dump would be a better
approach.

Well, a debugger comes to mind. :) But I'm sorry to say, I don't know
off the top of my head a special-purpose utility to do stack dumps. It
does seem like one could easily be written: it would act a lot like a
debugger, in that it would have to attach to the process and interrupt it,
but all it would have to do is use a PDB file to trace all of the stack
traces for each thread. How that would work with .NET code I don't know,
but I'm sure it's possible. :)

One advantage to using the external tool is that your application need not
be reliant on potentially removed methods, not would it have to carry
around diagnostic code that doesn't contribute to the application's main
purpose.

Pete