Threading hesitates in 2005

[Bob L.]

Hi everyone,

We have an application originally written in VS2003 that spawned a number of
threads (10-20 or so) for initialization of the application. Every thread
performs the exact same task in a few hundered milliseconds. In VS2003 the
app worked wonderfully.

Now we have upgraded the application to VS2005 using the exact same code.
After a number of threads kick off, the app suddenly pauses for anywhere
between a few seconds to a few minutes, apparently as a result of creating
the next thread. After the app pauses, the remaining threads are created and
run as if nothing happened.

Did something change in Visual Studio 2005 that would cause this behavior?

Thanks,
Bob

 

[Jon Skeet [C# MVP]]

We have an application originally written in VS2003 that spawned a number of
threads (10-20 or so) for initialization of the application. Every thread
performs the exact same task in a few hundered milliseconds. In VS2003 the
app worked wonderfully.

Now we have upgraded the application to VS2005 using the exact same code.
After a number of threads kick off, the app suddenly pauses for anywhere
between a few seconds to a few minutes, apparently as a result of creating
the next thread. After the app pauses, the remaining threads are created and
run as if nothing happened.

Did something change in Visual Studio 2005 that would cause this behavior?

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

 

[Bob L.]

Jon,

I am still working on putting together a program while balancing my other
tasks. In the mean time, I have a guess that this has something to do with
communicating from the threads to the user interface (I apologize for
leaving this out before). I know something changed in VS2005, because when
we upgraded we had to include more UI code inside our Invoke calls to avoid
UI threading exceptions (evidently the requirements are tighter in 2005).
Now if I comment out the calls to the UI, the app starts fine. Even though
the calls to the UI themselves don't hang the app, it almost appears as if
each call to the UI accumulates a delay that appears when starting a future
thread. Very strange.

In the mean time, I will continue to work on this demo app and try to find
the key to reproduce the problem.

- Bob

 

[Bob L.]

Well, I found the solution, but I still don't know the problem. It doesn't
appear to be UI related after all.

Before all the initialization threads kick off, there is one task that
executes on a single thread (there can be more than one, but in my test case
there is only one). If the first thread has a priority set to BelowNormal,
the initialization threads stop (hesitate) part way through startup. If the
priority of the first thread is Normal, everything works great. Any idea why
this is a problem in 2005, but not in 2003?

Thanks,
Bob

P.S. I still don't have a test app yet - I'll see what I can come up with.

 

[Jon Skeet [C# MVP]]

Well, I found the solution, but I still don't know the problem. It doesn't
appear to be UI related after all.

Before all the initialization threads kick off, there is one task that
executes on a single thread (there can be more than one, but in my test case
there is only one). If the first thread has a priority set to BelowNormal,
the initialization threads stop (hesitate) part way through startup. If the
priority of the first thread is Normal, everything works great. Any idea why
this is a problem in 2005, but not in 2003?

P.S. I still don't have a test app yet - I'll see what I can come up with.

It's possible that the priority of the JIT has changed between .NET 1.1
and .NET 2.0, so that while your thread used to have priority over the
JIT, it no longer does unless you've got a priority set to Normal.

Just a guess though...

 

[Michael D. Ober]

Sounds like there may be a bug in .NET 1.1's thread priority settings. If a
native Win32 App thread is at a low priority, other threads will run before
it. A perfect example of this was the Seti@Home Command Line Client 3.08
for Windows. It ran at Priority 4. Unfortunately, offline folders
syncronization in Windows XP and Outlook XP runs at either Priority 2 or 3.
Effectively the Seti client would freeze the offline folders features (and
in the case of Windows XP, the entire shell because this is a "critical
path" function in the shell). The SETI GUI client for windows properly set
itself to priority 1 in the system and didn't interfere with offline
folders. Eventually all runnable threads will execute because for every few
timeslices a thread doesn't get to run, the thread priority gets boosted
until it is has the highest priority of runnable threads. This behavior
exhibits itself as pauses and jerkyness in the execution of the thread.

As for "normal priority" in a thread. The default thread priority is 6.
Windows automatically boosts this to 7 for the thread that currently has the
keyboard/mouse focus to make user interfaces more responsive. This boost is
also given to the initial thread of an application that is launched with the
SW_NORMAL window option.

In your code, check for any Thread.Priority statements in your
initialization code and comment them out.

Mike Ober

Well, I found the solution, but I still don't know the problem. It doesn't
appear to be UI related after all.

Before all the initialization threads kick off, there is one task that
executes on a single thread (there can be more than one, but in my test case
there is only one). If the first thread has a priority set to BelowNormal,
the initialization threads stop (hesitate) part way through startup. If the
priority of the first thread is Normal, everything works great. Any idea why
this is a problem in 2005, but not in 2003?

Thanks,
Bob

P.S. I still don't have a test app yet - I'll see what I can come up with.

created