Board index » Visual Studio » How can retrieve a thread's state

Visual Studio165
All,



I can't find something to get the state(suspended, running..) of a thread,

Any suggestions ?



Thanks.


-

"JiangHan" <JiangHan@kdt.com.cn>wrote in message

In "normal" circumstances, the probability of a thread being in the running

state when observed from another thread would be very low (clearly zero on a

uni-processor system). Obviously cases like threads doing stuff like the

SETI application does are going to almost always be running but, if you look

at the Task Manager most processes spend most of their time off the

processor regardless of the number of threads they contain. That means most

threads spend most of their time waiting on something (usually input but, in

general, it could be stated more generally as waiting on I/O). Also,

particularly on a MP box, the reliability of any information you could get

about the state of a thread may be very low. If the thread is waiting on

I/O then that state could change before you get a result from your test

(since you can't measure I/O pre-emptions via interrupts on your thread that

polls the other threads). Your best chance of getting the information you

need using a documented method would appear to be the performance counter

features of Windows. As I understand it, these are the method that PerfMon

uses to monitor system parameters. PerfMon has a thread category and it has

state and wait reason sub-categories. Adding them to PerfMon for the

Explorer/0 thread I see that I can't provoke the state to change from 5 and

the wait reason to change from 13. However, I'm testing on a uni-processor

box and the PerfMon update can't run while the Explorer/0 thread is running

and the PerfMon polling interval is also huge with respect to the

pre-emption interval. The method looks cumbersome to me (polling a

statistic for many threads one at a time) and it may require some effort to

deduce if these two statistics are what they appear to be and if they are

even useful. I hope this helps.





-

"JiangHan" <JiangHan@kdt.com.cn>wrote in message

I couldn't find a way to get this information, and I suspect that it's

because you aren't suposed to use them for anything complicated. Keep in

mind that the only ways to suspend a thread safely are to create the thread

suspended, and to suspend the thread FROM WITHIN THE THREAD. If you suspend

the thread from outside it, you could suspend it while it holds a critical

section or other system resource, and then your application will die

horribly if it needs that resource. If your thread calls ANY third party

APIs, including system calls and MFC, you have to assume the APIs use

critical sections or acquire resources. For this reason, the SuspendThread

and ResumeThread functions are almost never useful.

Instead of suspending itself, perhaps your thread could wait on an event

or some other syncronization object, which can be queried by waiting on the

object with a timeout of 0. Unfortunately, I have no idea why the thread

needs to be suspended, so I can't offer a more specific suggestion.



Nathan Holt





-

"Nathan Holt" <nathanh@ccei-nm.com>wrote in message

It's not a big issue but I disagree. Suspend/Resume can be used like a

semaphore in some systems, particularly two thread parts of a process model.

In this model a thread suspends itself while waiting for data and the thread

that is the source of the data resumes it when the data is available. I've

built comms software using this model and wrote trivial wrappers around the

suspend/resume functionality so that all threads that suspend are placed on

a list and all threads that resume are removed from the list. This permits

all suspended threads to be resumed on application shutdown. The model was

quite effective in the case I used it for since it offered a small benefit

over the use of a semaphore.





-

"David A. Mair" <mairdanot@hotrmail.com>wrote in message

I stand corrected. Your use sounds quite reasonable.



Nathan Holt





-

In message <bsupec$q23$1@reader2.nmix.net>, Nathan Holt

<nathanh@ccei-nm.com>writes

Very useful though if you are writing low-level debugging tools and you

need to temporarily suspend threads whilst you modify a chunk of code.



If you want a tool to monitor the status of threads in an application

get threadStatus.exe from



www.objmedia.demon.co.uk/software.html">www.objmedia.demon.co.uk/software.html



Stephen

--

Stephen Kellett

Object Media Limited www.objmedia.demon.co.uk">www.objmedia.demon.co.uk

RSI Information: www.objmedia.demon.co.uk/rsi.html">www.objmedia.demon.co.uk/rsi.html

-

Hi Jiang,



SuspendThread and ResumeThread increment and decrement a suspend count on

the thread. You could potentially call SuspendThread and ResumeThread to

get the suspend count. If ResumeThread returns a value greater than 1, this

will indicate that the thread was previously suspended, before your call to

SuspectThread.



Another thought would be to post this question to a more appropriate

newsgroup like microsoft.public.platformsdk.base, or possibly

microsoft.public.win32.programmer.kernel.



Sincerely,

Ed Dore [MSFT]



This post is "AS IS" with no warranties, and confers no rights.



-