On Fri, 31 Oct 2008 10:42:37 -0700, Steven Blair
<st**********@btinternet.comwrote:
This video:
http://channel9.msdn.com/posts/Danie...k-and-friends/
Sorry, don't have time to watch it now (25 minutes!). I'll just assume it
says what you say it says (I haven't spent much time with the Parallel
Extensions, don't even have documentation handy for it right now).
Yeah I was really looking for clarification, and perhaps, this new API
is not what I need.
If Task1 must be completed before Task completes, this really throw out
using PFX for me (each Task should be able to run concurrently).
Any particular reason they have to run concurrently?
I was under the impression the PFX would let my threads running over
multi CPU's rather than queue up threads to process them more
efficiently.
My impression of the PFX is that the library is intended to make it easier
to write true parallelized algorithms without worrying so much about the
implementation of the parallelism and to maximize performance. Only by
restricting the number of concurrently running tasks can it do the latter.
Just as another question, my current code uses the ThreadPool. If I
kicked off 8 threads from this, would they automatically be assigned to
differen CPU's for free (so to speak)?
Even ThreadPool doesn't give you that kind of control over the threads.
You queue work items (i.e. "tasks"), not threads.
If you queue eight tasks all at once, and they run long enough, then
yes...eventually you'll get eight threads all running at once. By default
in .NET 2.0, a new thread is created only every half second, and you start
with one idle thread per processor. So, assuming a two-CPU system, it
would take another three seconds to add six more threads. If the first
task completes in less than three seconds, you won't get eight threads
working at the same time.
If you're doing i/o, and can guarantee that any given operation isn't
going to tie up a ThreadPool thread for _too_ long (i.e. longer than a
minute or so), then ThreadPool might well be reasonably appropriate. But
if you're writing CPU-bound code and have any interest at all in
maximizing throughput, then the PFX Task behavior may well be better.
As a general rule, it's counter-productive to insist on concurrently
executing threads for a group of related tasks. If for some reason you
actually have a legitimate exception to this rule, then you'd probably
want to avoid PFX, since in that case you'd have some goal that's mutually
exclusive with the most efficient use of the CPU.
Pete
