thread issue; works in NT not in 2K

[JimG]

Ok, I've got a large VC++ project that has been working just fine in windows NT 4.0. In moving to Win2K, we're noticing what appears to be a threading issue.

One of my worker threads which was created with THREAD_PRIORITY_NORMAL is not getting enough time unless (and here's the strange part) there's a Modal dialog box open.

This worker thread does some work, and then Suspends itself when done. In my primary window (derived from CMDIFrameWnd) I have an OnTimer event that Resumes the worker thread. The timer is set to 10ms.

It has been working just fine in WinNT 4.0 for some time. But in 2000 it's acting like the thread is only resuming once every 2 seconds or so. If I open a Modal dialog box, then the worker thread looks correct, but when I close it (returning focus to the CMDIFrameWnd class), it slows down again.

[JimG]

I'm now experimenting with thread priorities. Increasing the priority of the worker thread and/or decreasing the priority of the Application's primary thread (is this a UI thread???) does improve the performance, but it's still not 100%.

Do the two OS's interpret thread priorities differently?

[JimG]

Actually, it looks like my threads are all UI threads, not worker threads. Dunno if that makes a difference.

[NigelQ]

Jim,

Manipulating thread priorities almost never is a good idea, so I'd suggest giving up this approach.

One thing that would help would be an understanding of what your threads are up to at any given time.

Also, what is your process's CPU utilization like in both OS's? Worker threads (even busy ones) should *never* reach 100%. If the thread is idle and waiting for something, it should be at almost 0% utilization, and even if it's extremely busy doing something, it should sleep every now and then to permit essential tasks and messages being processed.

A good idea is to put plenty of sleep statements in your worker threads (something that most people forget).

Your sleep statements should be as big as you can handle if the thread is idle (~200ms minimum for an idle thread).

The only time that altering thread priorities makes any sense at all is when you are interacting with hardware, otherwise you interfere with the OS's task scheduler, and in addition, you actually very rarely get the effect you think you should get by changing the priority.

Hope this helps,

- Nigel

[JimG]

Actually, my thread is talking to hardware. It's collecting data off of a video capture card and buffering it to PC memory. It also has a child thread that takes it out of RAM and writes it to disk.

We've seen the issue on multiple machines, but the one I'm currently testing on is an older box. P3 800Mhz.

Okay, we're on to something with the CPU usage:

In Win 2K when I see performance go down, the process is at 100% CPU usage. When I open a Modal dialog box, and things are working normally, CPU usage ranges between 2% and 20%.

Same thing in NT 4.0, however even when the usage is at 100%, it's working fine.

Is there a tool that looks at CPU usage by thread? As far as I can tell, Spy++ isn't much help.

Ok, so what is going on behind the scenes when a Modal dialog box is created that brings the CPU usage down? Essentially, the thread that opens it (in this case, the main application thread) waits for it to return, so it isn't do any message handling?

[JimG]

Is there a tool that looks at CPU usage by thread?

Why yes, there is. In NT the Performance Monitor does it.

Sure enough when I activate my video thread, one thread of the application goes up to about 90%. When I open a modal dialog, that thread goes to 0. The threads aren't named, but they are numbered, and the thread in question is #0, so I assume this is the application's primary thread.

[MikeAThon]

This is an "out there" kind of idea, but I think your problem might have more to do with pumping of messages than thread priority.

When a modal dialog is displayed, Windows wrests control away from your application and runs its own message pump. The message pump of your own application is never called so long as the modal dialog is displayed.

Try showing a simple MessageBox instead of your modal dialog, and see if you get the same results.

If you do, then I would focus attention on any special use you might make of messages in your app's main message pump. If this is an MFC app, for example, then the call to PreTranslateMessage is made directly from the message pump (see the source code for CWinThread::PumpMessage). During a modal dialog, since it's Windows that runs the message pump, PreTranslateMessage would not be called. Are you perhaps doing things in PreTranslateMessage that load down the CPU when the modal dialog is not running, and that are not executed when the modal dialog is running?

Sorry if this idea completely misses the mark. As I said, it's "out there".

-Mike

[JimG]

Yes, it's an MFC app. No, I don't see the performance improvement in a standard dialog box, except when I click and hold the mouse on the dialog frame.

I agree that it's more of a message pump issue than a thread priority issue. The main thread only goes to 90% CPU after we launch (actually Resume(), they're already created, just Suspended) the child threads.

I'm getting closer now. Putting a Sleep command in the OnIdle method of the primary thread improves things. Weird, huh?

Thanks for the help, guys.

[NigelQ]

Jim,

If performance is an issue for your worker thread, you could put sleep(0)'s around your worker thread (that's running close to 100%). This will force the thread to give up the remainder of it's quantum (time-slice), donating it to other threads that need them.

This may have minimal impact on your busy thread, but have a significant effect on the others.

It's basically a hint to the thread scheduler that helps it allocate these time-slices.

Hope this helps,

- Nigel

[JimG]

It was indeed a messaging issue. Someone (prior to me working on the project) had inserted a message to constantly force a time update while we are displaying video.

I took that out, and now my CPU utilization never goes above ~25%.

It still amazes me that we worked fine in NT, but not in 2K. The problem was definetly there