views:

318

answers:

6

I have a program that uses:

ThreadPool.QueueUserWorkItem(new WaitCallback(FireAttackProc), fireResult);

On Windows7 and Vista it works fine.

When I try to run it on XP the result is a bit different from the others.

I was just wondering in order to execute QueueUserWorkItem properly do I need a dual CPU system?

The XP I tried to test on had .Net 3.5 installed.

Inputs most welcome.

EDIT: The callback proc plays a series of sound files. in win7 and vista they all play. but in xp only a couple of them plays. I get no exceptions from the program.

EDIT: Yes the XP box is single core. more than 5 years old.

EDIT: My app uses Winsock and I ran both the client and server on the XP machine. I will try running it with a single instance per machine and see how it reacts.

EDIT: How are you playing the sounds?

            SoundPlayer fire = new SoundPlayer(Properties.Resources.fire);
            fire.PlaySync();
            fire.Dispose();
A: 

Performance should be better on multiple CPU's, but calculation results should be the same as on single core machine. If you have different calculation results, this might be thread synchronization issue. ThreadPool.QueueUserWorkItem works on multicore and single core machines.

Al Bundy
+2  A: 

The main difference is that, on a single core system, only one thread can run at a time. If your program is designed properly, this shouldn't matter, as the operating system switches the threads in and out and manages this for you.

If you're seeing a difference on a single core system, this most likely means you have a race condition in your code. The only difference should be that it takes longer - since the OS can't run both threads concurrently.

Reed Copsey
A: 

What exactly did you see?

Timing with threads is non-deterministic, so it is not surprising you saw different results if you ran it on a single processor machine. That is because with only a single core (without hyperthreading), a single instruction can only execute at once, so you will not see true parallel execution.

BUT, windows XP supports multiple cores, just like Windows 7 or Vista. I assume the XP machine you ran it on was older, and only had 1 CPU?

Justin Ethier
A: 

You might be hitting problems with the sound file play API. The below link talks about problems playing multiple sound files at very fast intervals or close to simultaneously using PInvoke from a C# app. Could this be similar to your issue?

http://www.hanselman.com/blog/CategoryView.aspx?category=BabySmash&page=3

James Pogran
+1  A: 

Vista and Windows 7 handle audio differently from Windows XP, so that's probably the real source of your problem (i.e. it has nothing to do with QueueUserWorkItem).

How are you playing the sounds (since there are many different ways you could be doing this)?

Edit: When you say you're playing a "series" of sounds, do you mean you're trying to play one sound after another, or you're trying to play a bunch of sounds all at the same time?

MusiGenesis
yep. I mean one after another, not a bunch at the same time.
iEisenhower
Are you using QueueUserWorkItem to call a method once, that then plays a bunch of files one after the other, or does the method only play one file, and you're using QueueUserWorkItem to call the method a bunch of times?
MusiGenesis
It would help if you posted a more complete piece of code.
MusiGenesis
+1  A: 

The behavior of the ThreadPool manager matters. It tries to carefully avoid scheduling more threads than you have cores. So if your XP machine has a single-core CPU, it will only allow one thread to run. Only when threads get "stuck" and do not complete in a timely manner will it allow another thread to start. These scheduling decisions are made twice a second.

Given that you are using threads to play sounds, a thread pool thread is not the appropriate solution. You should create your own Thread.

Hans Passant