Should I notice a difference in using Task vs Thre

问题:

I updated my code to use Tasks instead of threads....

Looking at memory usage and CPU I do not notices any improvements on the multi-core PC, Is this expected?

My application essentially starts up threads/tasks in different objects when it runs...

All I'm doing is a simple

Task a = new Task(...)
a.Start();

回答1:

There are various implications to using Tasks instead of Threads, but performance isn't a major one (assuming you weren't creating huge numbers of threads.) A few key differences:

1. The default TaskScheduler will use thread pooling, so some Tasks may not start until other pending Tasks have completed. If you use Thread directly, every use will start a new Thread.
2. When an exception occurs in a Task, it gets wrapped into an AggregateException that calling code can receive when it waits for the Task to complete or if you register a continuation on the Task. This is because you can also do things like wait on multiple Tasks to complete, in which case multiple exceptions can be thrown and aggregated.
3. If you don't observe an unhandled exception thrown by a Task, it will (well, may) eventually be thrown by the finalizer of the Task, which is particularly nasty. I always recommend hooking the TaskScheduler.UnobservedTaskException event so that you can at least log these failures before the application blows up. This is different from Thread exceptions, which show up in the AppDomain.UnhandledException event.

回答2:

If you simply replaced every usage of Thread with Task and did no other changes I would expect virtually the same performance. The Task API is really just that, it's an API over an existing set of constructs. Under the hood it uses threads to schedule it's activities and hence has similar performance characteristics.

What's great about Task are the new things you can do with them

• Composition with ContinueWith
• Cancellation
• Hierarchies
• Etc ...

回答3:

One great improvement of Takss vs. Threads is that you can easiely build chains of tasks. You can specify when a task should start after the previous task ("OnSuccess", "OnError", a.s.o.) and you can specify if there should be a synchronization context switch. That gives you the great opportunity to run a long running task in bakcground and after that a UI refershing task on the UI thread.

回答4:

If you are using .Net 4.0 then you can use the Parallel.Invoke method like so

Parallel.Invoke(()=> {
    // What ever code you add here will get threaded.
});

for more info see http://msdn.microsoft.com/en-us/library/dd992634.aspx

回答5:

You would see difference if your original or converted code do not utlize CPU completely. I.e. if original code always limited number of threads to 2, on quad-core machine it will run at about 50% load with manually created threads and potentially 100% load with tasks (if your tasks can be actaully paralellized). So it looks like either your original code was reasonable from performance point of view, or both implemetaion suffer issues showing similar underutiliztion of CPU.