Monitor thread status

[George2]

Hello everyone,


Any tools I could use to monitor (x64 platform) the status of all threads inside a specific process?

For example, wait for a handle (convenient to analyze deadlock), sleep, running? Since my application deals with I/O heavily, it is good if the tool could monitor I/O thread's status -- e.g. sent request, waiting response or something?


thanks in advance,
George

[DreamShore]

I'm not sure if vTune can do such jobs. But I think you can just collect the data yourself, since it is your ownapplication.

[George2]

Thanks DreamShore,


1. vTune is not free?

2. "collect the data yourself" you mean I add debug code inside my application manually? :-)

I'm not sure if vTune can do such jobs. But I think you can just collect the data yourself, since it is your ownapplication.


regards,
George

[DreamShore]

1. Not free, but can be used for free for several days though...

2. Log events and analyze them. More or less, just debug code, used for some automatic analyzing.

[George2]

Thanks DreamShore,


Do you know whether Visual Studio or WinDbg has some thread monitor function? :wave:

1. Not free, but can be used for free for several days though...

2. Log events and analyze them. More or less, just debug code, used for some automatic analyzing.


regards,
George

[DreamShore]

It seems that it doesn't have. The analyzer visual studio provides is very limited. Windbg, not at all.

I guess it doesn't hurt to collect it yourself if the application isn't too large.

[George2]

Thanks for sharing your experience and advice, DreamShore!


Actually, I have not did similar things before, could you describe the basic ideas, or some documents about how to do that please? :wave: ;)

It seems that it doesn't have. The analyzer visual studio provides is very limited. Windbg, not at all.

I guess it doesn't hurt to collect it yourself if the application isn't too large.


regards,
George

[DreamShore]

Just what I do.
Give each position the context would change (e.g. before and after EnterCriticalSection() or WaitForSingleObject) an id. Store the events that the execution reachs those positions with the time.
And something tricky. You might need to synchronize the IOs manually, otherwise you would not know whether the function is working or waiting. It's not accurate even you synchronize by yourself, much better though.

Now you can get the picture how threads are working on the timeline.

I believed there should be a function on the CPU that can monitor task switching. But I haven't seen into what is it for now.

[George2]

Thanks DreamShore,


What means "need to synchronize the IOs manually"? Could you show me a sample scenario?

Just what I do.
Give each position the context would change (e.g. before and after EnterCriticalSection() or WaitForSingleObject) an id. Store the events that the execution reachs those positions with the time.
And something tricky. You might need to synchronize the IOs manually, otherwise you would not know whether the function is working or waiting. It's not accurate even you synchronize by yourself, much better though.

Now you can get the picture how threads are working on the timeline.

I believed there should be a function on the CPU that can monitor task switching. But I haven't seen into what is it for now.


regards,
George

[DreamShore]

Like

// switching out
EnterCriticalSection(&disk_guard);
// switching in
ReadFile(...);
LeaveCriticalSection(&disk_guard);


Or you can just get from what time to what time the thread is executing which IO. That will tell someting useful, too, but not the time waiting. For network, synchronizing is a little meaningless since network IO can be thinked as just waiting.

[George2]

Thanks DreamShore,


Two more comments,

1.

I think we can get the waiting time, by tracking the time before EnterCriticalSection and after EnterCriticalSection. Any comments?

2.

What do you mean "For network, synchronizing is a little meaningless since network IO can be thinked as just waiting."? Could you say in some other words please? My English is not very good. :-)


regards,
George

[DreamShore]

1. Not exactly. You can get the how the threads work accord to the timeline. There may be two or more thread running at the same time. They could wait each other for cpu resource at that period. We can not get such detail unless we trace the task switchings. We don't need such detail any way.

2. Something like, normally, network is not blocked by the bandwidth, but waiting for the action of the remote side. You don't have to know how much time it takes to send or receive bits. Not quite possible either if you are not working on a single socket.

I think logging with code is really limited 0_0...

[George2]

Thanks DreamShore,


1.

1. Not exactly. You can get the how the threads work accord to the timeline. There may be two or more thread running at the same time. They could wait each other for cpu resource at that period. We can not get such detail unless we trace the task switchings. We don't need such detail any way.

Why we need to track task switchings in order to get the wait time? I think just check the time differences between before entering a lock and after entering a lock is fine. You think it is not wait time? :wave:

2.

2. Something like, normally, network is not blocked by the bandwidth, but waiting for the action of the remote side. You don't have to know how much time it takes to send or receive bits. Not quite possible either if you are not working on a single socket.

I think logging with code is really limited 0_0...

You mean there is no API to get the exact time on wait for socket?


regards,
George

[DreamShore]

The system will put one thread waitng and an other running automatically from time to time if you has more threads than execution cores. When you see two threads running together they may just switching.

I found there is an entry called "performance monitoing" in msdn docment... I don't know if it can do such things.

About the time waiting on a socket. What are you dealing with?

[George2]

Thanks DreamShore,


My purpose is to find out which thread may be deadlock -- i.e. always wait for something. Any ideas to use any tools to do it?

The system will put one thread waitng and an other running automatically from time to time if you has more threads than execution cores. When you see two threads running together they may just switching.

I found there is an entry called "performance monitoing" in msdn docment... I don't know if it can do such things.

About the time waiting on a socket. What are you dealing with?


regards,
George

[DreamShore]

If that's so debug logging is more than enough. You can surely find out if a thread go out and never come back.

[George2]

Thanks DreamShore,


Do you have any referred documents? For such manual debugging techniques, I am afraid it is prone to make some mistakes and I want to prepare to learn from others in advance. :-)

If that's so debug logging is more than enough. You can surely find out if a thread go out and never come back.


regards,
George

[DreamShore]

Usually it's merely a worker thread writing queued data to somewhere, if it is just logging. Not much technique @@...

[George2]

Thanks DreamShore,


Good to learn from you from the long discussion. Hope there will be some such type of tools in the future. :-)

Usually it's merely a worker thread writing queued data to somewhere, if it is just logging. Not much technique @@...


regards,
George