Developer Forum

Just recently, I happened came across one .net multithreading book saying
that multithread programs might get differential in stability when running
on single CPU machine compared to a multi-CPU one.The book also recommands a
way in .NET to run specific thread on specific CPU.

Now I am facing a new project which is going to be deployed to either a
single or a multiple CPU machine. My problem is: can .NET 'automatically'
detect CPU status and distribute threads created by my program to all the
installed CPUs, in other words, without 'manually' set in the program for
the thread to be specific CPU centric, can a multithreaded program fully
utilized the CPU resources provided by the system?

I am quite confused about that, could anyone of you give me some advice,
thanks and appreciated.

Just recently, I happened came across one .net multithreading book saying
that multithread programs might get differential in stability when running
on single CPU machine compared to a multi-CPU one.The book also recommands a
way in .NET to run specific thread on specific CPU.

Now I am facing a new project which is going to be deployed to either a
single or a multiple CPU machine. My problem is: can .NET 'automatically'
detect CPU status and distribute threads created by my program to all the
installed CPUs, in other words, without 'manually' set in the program for
the thread to be specific CPU centric, can a multithreaded program fully
utilized the CPU resources provided by the system?

I am quite confused about that, could anyone of you give me some advice,
thanks and appreciated.

What exactly do you mean by "differential in stability"?

Certainly there are multi-threading bugs which you probably won't
notice if you're only running on a single CPU - but if your code is
properly written, it shouldn't become unstable on multiple CPUs. You
shouldn't need to run specific threads on specific CPUs.


It automatically distributes them - at least, I believe it's the OS
that does it rather than .NET itself. I don't know whether threads can
migrate from one CPU to another though...

--
Jon Skeet - < XXXX@XXXXX.COM >
http://www.yqcomputer.com/ ~skeet
If replying to the group, please do not mail me too

Hi Tommy,

a

You have to be more specific on this. Exactly what the sugest? .NET has
some improved support for threading API (like ThreadPool ) that older MS OS
versions didn't support, or support but through some not
well-documented/not-so-common APIs, like IOCP. Because of that most
programmers usually code they're thread in a fire-and-forget behavior, wich
is not a good aproach if you're doing,for example, server applications.
However, as Jon stated before, once the thread is created, it is a
thread that's all. from an OS, or processor, perspective any thread will
behave the same way.


Yes, this could happen, but because of .NET. the Windows 2000/XP/2003
and others do that. This is a OS task, not .NET task, and there is no other
way to be done. Once there is threads started, the OS should, at some point,
allow the thread to be acessed by the processor to be processed :).
If you have thread dependencies that impose a situation where one thread
should be performed after other thread job, you should by some how
synchronize them, suspending the dependent thread execution until the other
thread signal that it completes it's job.
Being "CPU centric" means that you buy a $$$ hardware with 4 processors,
but will keep 3 of them unused, right?
For curios, in which book you see that? Is this a "good practice"
recomendetion from it?

Cheers,

Eric

They can even though it incurs the hit of having the load the cache for that
CPU rather then run on a warm cache on the same CPU. Using Win32 API's it's
possible to set thread affinity but that's not exposed in .NET (nor should
it be) since it is non-portable. Besides, the OS can usually make better
decisions about which CPU to run a thread on than an application.

thx guys for your post.
The book I am refering is manning's '.net multithreading'
and the .NET do provide a way to specify thread to a
target CPU. It's through ProcessThread.IdealProcessor
Property.
Anyway, I think I can draw the following conclusion of
this question:
system will manage threads created by .NET program and
only reason to improve the performance by mannually set
thread to be running on a specific CPU is because of the
improvement of CPU cache hit.
Am I right

multithreading book saying
stability when running
book also recommands a
deployed to either a
can .NET 'automatically'
program to all the
in the program for
multithreaded program fully
me some advice,

On Wed, 14 Jul 2004 06:39:19 -0700, "Tommy"



On a shared memory multiprocessor, load operations are typically
extended to include checking the caches of the other CPUs. There is a
slight reduction in performance when code or data must migrate from
one cache to another, but migration is still much faster than loading
anything from RAM.

Keep in mind that migration is performed incrementally as the code
executes - just like all other cache operations. The CPU that
previously executed the thread will go on about it's business and may
displace the thread's data from it's cache before that data can be
migrated to the thread's current CPU.

In an active system with many runnable threads it usually makes no
difference which CPU executes a thread because it is likely that all
of the thread's code and data will be displaced before the thread is
scheduled to run again.

George
--
for email reply remove "/" from address