Re: getting a thread's state and CPU utilization

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"David Jones" <ncic@xxxxxxxxxx> wrote in message
news:MPG.20148e47ade142d29896b0@xxxxxxxxxxxxxxxxxxxxxxxx
Dennis Jones <nospam@xxxxxxxxxx> wrote...
Using the Win32 API, does the OS provide the means to determine the state
of
a thread -- that is, running, suspended, or waiting on a synchronization
object via one of the Wait... calls (knowing the type of synchronization
object and/or what Wait... function was used would be nice too, but not
critical)?

From user mode, the Debug API might give you most of what you need:

http://msdn.microsoft.com/library/en-us/dndebug/html/msdn_debugEH.asp

Thank you for the link, I'm sure I'll find some useful information therein.


Also, is it possible to determine a thread's current CPU utilization
(i.e. %
of CPU time currently being used)? I can get the total time used by a
thread via GetThreadTimes, but that doesn't tell me what the thread is
doing
*right now.*

At any particular point, a thread is either using 100% of a processor or
0% of a processor (running or not running). So, for total CPU usage, a
thread is either using 0% or (100/#processors)%.

Oh, duh!!! Of course, you're absolutely right -- I didn't even think of
that! The only thread using the CPU will be the one logging the data!


Barring any of the above, are there known techniques for detecting
when/if a
thread is :

a) one of the participants of dead-lock
b) a particpant in a race condition
c) in an infinite (possibly very tight) loop

Wow. These are pretty difficult to detect these in the general case,

You couldn't just look for a long blocking wait since it might be
legitimate, such as a shell replacement program blocking on a process
handle that the user hasn't terminated or an application blocking on an
event triggered by hardware that only occurs rarely.

Yeah, I guess dead-lock would be pretty hard to detect. Fortunately,
dead-lock isn't a problem my application has (knock wood)!


Similarly, there's so many ways to create race conditions and infinite
loops that it's very complex to try to detect all situations that would
cause them. How could you tell an infinite loop from a polling loop
around some circumstance that takes a really long time to complete? (As
in the long blocking wait above.)

Well, in my case, I think I can make some educated guesses about how busy my
threads should be. For instance, if a thread should be asleep most of the
time, waking up just long enough to respond to some event, and if, over some
period of time, I can see (via GetThreadTimes) that the thread's usage time
is increasing at some unusually high rate, then that is a pretty good
indicator that something is wrong (like maybe the thread is stuck in an
infinite loop). Obviously, if a thread ran frequently or for long periods
of time, then this would be more difficult, but I'm lucky enough to know
that most of my threads should be asleep in a wait state most of the time.


Maybe if you were more specific as to why you need this information we
might be able to point you in the right direction. Sorry I couldn't be
any more help.

On the contrary, you've been very helpful. But to answer your question, I
have a TCP/IP server application that has been running fine in many
different environments for over a year. However, I recently received a
report where my application eventually begins to monopolize the CPU,
utilizing somewhere between 80-90% of the CPU's time, and the customer
states that he must kill my application's task in order to stop and restart
it. In addition, he states that the number of connections to my app (from
their client application) is extremely high (20-40 connections, when 1 (or
maybe 2) is typical).

An open TCP connection by itself does not concern me because my application
will sit quietly doing nothing until it must respond to an incoming message
from the client -- and even then, it is able to reply and process messages
at a rate of about 30-40 messages/sec, then it goes back to sleep to wait
for more messages. [In my own testing, even when it is extremely busy
responding to continuous messages from many client apps, my app's CPU
utilization is still very reasonable (<5-10%).] When I looked at the log
files though, I could see that the client application was never
disconnecting (at least not as far as my application was concerned) even
though the customer *claims* that the client app is disconnecting (I suspect
there is something unusual about the client application or how it
disconnects, as this has never happened before at other sites).

So, based on this information, and unable to get too much more out of the
customer, I have to make some guesses and try to find a way to replicate
and/or detect these two problems. At the moment, I don't really know how a
TCP/IP application could disconnect without my application detecting it, so
I am concentrating on the symptom of very high CPU utilization (which is
more of a concern to me than a high number of connections), hoping that if I
can figure out which thread is so busy that the app no longer responds, that
it will lead me to discover why I don't see the client disconnections.

Based on your response and another I received elsewhere, I think my plan of
attack is going to be to periodically call GetThreadTimes() for each thread
and keep some kind of weighted average that, when tipped too far will
trigger the generation of log information including the thread's ID and call
stack. I don't want to log everything all the time or my log will get so
big that it would be impossible to wade through, so the trick is going to be
getting the weighting right and setting the trigger point at a reasonable
value.

Does this seem like a reasonable approach?

Thanks very much for your feedback,

- Dennis


.

Relevant Pages

  • Re: Cost of calling a standard library function
    ... It accesses/reads memory using esi 4 ... > safly move it within the cache, without having to go via ebx. ... try it the same thing on a different earlier CPU, ... should check it out...for "tight inner loop" stuff, ...
    (alt.lang.asm)
  • Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions
    ... the terminology is less useful than it might be. ... though a "message loop" could arguably be claimed to be ... considering in a particular iteration but what is true for _ALL_ ... watching the "polling" version eating up every single CPU cycle ...
    (alt.lang.asm)
  • Re: Detect the loop for batch job
    ... We are looking for a tool to detect the loop for batch application, ... step is to impose and enforce standards requiring reasonable CPU TIME ...
    (bit.listserv.ibm-main)
  • Re: Is Message passing good approach for multi-threaded applications?
    ... that it's hard to even create an artificial case where select loop is ... client gets to wait while each file read for that client blocks. ... And never ever blocking on pain of death doesn't introduce overhead ... This is from lots of painful experience. ...
    (comp.unix.programmer)
  • Re: sched_yield() problems...
    ... register in the CPU core. ... This is a 64 bit register that count the clock ... loop, I get reaction time of less than 10 us. ... In fact, I don't know why your gettimeofday don't work, so don't blame ...
    (alt.os.linux.redhat)