, blowdart wrote

*snip*

Oh not true sir. If I have 3 running tasks that are isolated from each other, but something needs the results of all 3 then that's a perfect use for threading.

Perhaps I should have been more clear - I meant Thread the type, not Threading the concept.

System.Threading.Threads should be for tasks going on in the background.

If you're dealing with concurrent actions that you want to use in parallel, use something like Future<T> (or possibly BackgroundWorker).

Future<int> a = new Future<T>( () => Gen1 );
Future<int> b = new Future<T>( () => Gen2 );
Future<int> c = new Future<T>( () => Gen3 );
int d = Gen4();

return d + a.Value + b.Value + c.Value;

 

System.Threading.Thread shouldn't be used for anything other than a long-running parallel thread of execution (e.g. parsing a file in the background or handling incoming/outgoing network and pipe connections) - and in general you shouldn't need to Join with it to block the UI, you'll want to expose an event instead to let the UI remain smooth whilst doing the processing. System.Threading.Thread has a punishingly high startup cost. Don't use them for short running tasks or stuff that you're going to wait on. (Task and BackgroundWorker amortize the cost by using a threadpool, which is much better).