Stacktrace class and CLR 2.0

[rani.yaroshinski]

Hi all,

The Stacktrace class (system.diagnostic) in CLR 2.0 (Framework 2.0),
still offers a constructor to allow showing the stack-trace of another
thread. However, the usage involves suspending the diagnosted thread.

Now, CLR 2.0 turns the Suspend method into obsolete, which leaves the
above quite impossible/useless (it is still possible in theory, cause
you can use obsolete methods).

I wonder whether the Stacktrace con was just forgotten, or there is
some new way to write and manage threads, so it will be possible to
diagnose other threads ...

If some of you, are unable to find reason for this, I'll give one.
Assume a thread is stuck in a multithreaded program (maybe in
deadlock), and I would like to abort it, but first write its state to
log, in order to be able to fix the problem later.

Regards,
Rani

 

[Carl Daniel [VC++ MVP]]

Hi all,

The Stacktrace class (system.diagnostic) in CLR 2.0 (Framework 2.0),
still offers a constructor to allow showing the stack-trace of another
thread. However, the usage involves suspending the diagnosted thread.

Now, CLR 2.0 turns the Suspend method into obsolete, which leaves the
above quite impossible/useless (it is still possible in theory, cause
you can use obsolete methods).

I wonder whether the Stacktrace con was just forgotten, or there is
some new way to write and manage threads, so it will be possible to
diagnose other threads ...

I don't think it was forgotten. In fact, suspending a thread is a well
defined mechanism, it's simply not appropriate to use for inter-thread
synchronization, which is why it's been deprecated in .NET (and Java and
many other frameworks). In this case, the thread is supended for the
express purpose of capturing it's state, and then it's allowed to run free
again. There's no risk that the thread will be left in the suspended state.

If some of you, are unable to find reason for this, I'll give one.
Assume a thread is stuck in a multithreaded program (maybe in
deadlock), and I would like to abort it, but first write its state to
log, in order to be able to fix the problem later.

Here's another example - the debugger API makes frequent use of thread
suspension to examine and modify the state of threads in the debugee. Of
course, that's not unlike the use case for StackTrace and is a perfectly
acceptable and safe use of thread suspension.

-cd

 

[rani.yaroshinski]

As much as I know, obsolete functions are a recommendation for the
user, to avoid. I guess that in coming version this function will not
be supported anymore. Your argument is that for these cases, it is
correct to Suspend a different thread.

BTW, I am not sure that if the thread is stuck in some deadlock it will
be possible to suspend it.

 

[Carl Daniel [VC++ MVP]]

As much as I know, obsolete functions are a recommendation for the
user, to avoid. I guess that in coming version this function will not
be supported anymore. Your argument is that for these cases, it is
correct to Suspend a different thread.

BTW, I am not sure that if the thread is stuck in some deadlock it
will
be possible to suspend it.

It's always possible to suspend a thread unless it's stuck compute bound in
the kernel. If it's simply blocking on I/O, a mutex, or other
syncronization mechanism, then it's already suspended and suspending the
thread is nothing more than moving the thread from one kernel list to
another.

The other complication with thread suspension (that didn't occur to me last
night) is that if you're running the CLR inside SQL Server and SQL Server is
running in fiber mode, then CLR threads don't correspond directly to kernel
threads and may in fact be fibers. In that case, it may not be possible to
suspend a thread that's compute bound in user-mode code, since suspension is
voluntary in fiber mode.

Some future version of the CLR may implement a hybrid model where it uses
some number of OS threads (e.g. 2x the number of cores) and then uses fibers
(similar to the "Green Threads" used by some JVM implementations) on top of
those OS threads. In such a model, thread suspension in general would have
the same problems that one can encounter in SQL Server today.

-cd