Are multithreaded apps bound to a single core?

Question

Hi,

I'm running a .NET remoting application built using .NET 2.0. It is a console app, although I removed the [STAThread] on Main.

The TCP channel I'm using uses a ThreadPool in the background.

I've been reported that when running on a dual core box, under heay load, the application never uses more than 50% of the CPU (although I've seen it at 70% or more on a quad core).

Is there any restriction in terms of multi-core for remoting apps or ThreadPools?

Is it needed to change something in order to make a multithreaded app run on several cores?

Thanks

Answer 1

Multi-threaded apps are not required to be bound to a single core. You can check the affinity (how many cores it operates on) of a thread by using ProcessThread.ProcessorAffinity. I'm not sure what the default behavior is, but you can change it programmatically if you need to.

Here is an example of how to do this (taken directly from TechRepublic)

Console.WriteLine("Current ProcessorAffinity: {0}", 
                  Process.GetCurrentProcess().ProcessorAffinity);

Process.GetCurrentProcess().ProcessorAffinity = (System.IntPtr)2;

Console.WriteLine("Current ProcessorAffinity: {0}", 
                  Process.GetCurrentProcess().ProcessorAffinity);

And the output:

Current ProcessorAffinity: 3
Current ProcessorAffinity: 2

The code above, first shows that the process is running on both cores. Then it changes to only use the second core and shows that it is now using only the second core. You can read the .NET documentation on ProcessorAffinity to see what the various numbers mean for affinity.

Answer 2

There shouldn't be.

There are several reasons why you could be seeing this behavior:

1. Your threads are IO bound.

   In that case you won't see a lot of parallelism, because everything will be waiting on the disk. A single disk is inherently sequential.

2. Your lock granularity is too small

   Your app may be spending most of it's time obtaining locks, rather than executing your app logic. This can slow things down considerably.

3. Your lock granularity is too big

   If your locking is not granular enough, your other threads may spend a lot of time waiting.

4. You have a lot of lock contention

   Your threads might all be trying to lock the same resources at the same time, making them inherently sequential.

5. You may not be partitioning your threads correctly.

   You may be running the wrong things on multiple threads. For example, if you are using one thread per connection, you may not be taking advantage of available parallelism within the task you are running on that thread. Try splitting those tasks up into chunks that can run in parallel.

6. Your process may not have a lot of available parallelism

   You might just be doing stuff that can't really be done in parallel.

I would try and investigate each one to see what the cause is.

Answer 3

Multithreaded applications will use all of your cores.

I suspect your behavior is due to this statement:

The TCP channel I'm using uses a ThreadPool in the background.

TCP, as well as most socket/file/etc code, tends to use very little CPU. It's spending most of its time waiting, so the CPU usage of your program will probably never spike. Try using the threadpool with heavy computations, and you'll see your processor spike to near 100% CPU usage.