Re: threading choice on single/multiple CPU
From: Eric Paschoalick Chaves (ericchaves)
Date: 07/14/04
- Next message: Peter Jaušovec: "Re: Textbox"
- Previous message: Jon Skeet [C# MVP]: "Re: Low .NET Socket performence!!!"
- In reply to: Tommy: "threading choice on single/multiple CPU"
- Next in thread: Tommy: "threading choice on single/multiple CPU"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 14 Jul 2004 06:36:17 -0300
Hi Tommy,
> 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.
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.
> 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?
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
- Next message: Peter Jaušovec: "Re: Textbox"
- Previous message: Jon Skeet [C# MVP]: "Re: Low .NET Socket performence!!!"
- In reply to: Tommy: "threading choice on single/multiple CPU"
- Next in thread: Tommy: "threading choice on single/multiple CPU"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
