3

The new async language features in c# 5.0 rely heavily on the Task object, and lots of examples show that one common way to run some of your code in a Task is to start it via Task.Run(), which represents your code as a Task and runs it on a threadpool thread.

However, I also have read that one should not start long-running code on the threadpool threads, which leads me to this question: is it possible to still use all the C# async language features (such as Task, 'await', 'async') on "regular" threads and not use the threadpool? In this case, how would one get a Task object representing code running on a "regular" thread?

And as a follow up question about the rule of not running long-running code in the threadpool - is this rule only about code that is cpu intensive? What if your code runs a long time (72 hours, for example) but spends most of its time doing things like "await Task.Delay()".. is it then okay to use threadpool threads, or should one use "regular" threads in all cases where your concurrent code needs to run for a long time?

CodeLikeBeaker
  • 20,682
  • 14
  • 79
  • 108
Michael Ray Lovett
  • 6,668
  • 7
  • 27
  • 36

2 Answers2

3

You can run Tasks wherever you want by making a custom TaskScheduler.

However, if all you're doing is await Task.Delay(), you shouldn't bother.
The whole purpose of asynchronous calls is to not hold up a thread while waiting for something to happen. While you're awaiting Task.Delay(), there aren't any threads running at all.

If you're actually running synchronous code for a long time, you can specify TaskCreationOptions.LongRunning to force it to create a new thread.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • My app is "servicing" 40 concurrent Amazon Ec2 instances for up to 72 hours, and servicing for each instance looks like this: "Download a file and process it; Wait 15 seconds and get another kind of file and process it. Wait 15 seconds and execute a remote SSH command".. etc. Instead of doing this all sequentially to one EC2 instance after another (which doesn't scale well), I'm servicing all instances "in parallel" using Task.Run(). But as I add more and more code (and waits) I'm wondering if using the threadpool is a mistake? – Michael Ray Lovett Nov 08 '12 at 23:12
  • 2
    @MichaelRayLovett: It's only a mistake if you have a long-running **synchronous** operation. Anything happening during `await` does not consume a thread. (assume you're awaiting a well-written awaitable) – SLaks Nov 09 '12 at 03:49
3

I also have read that one should not start long-running code on the threadpool threads

The thread pool will respond to long-running code correctly, so it's not like you can't do it - it's just not the most efficient way to do it.

Also note that Task.Delay implies the opposite of "long-running" - the individual Task actually completes at the point of the await and is no longer on the thread pool. Another Task is created and queued to the thread pool when Task.Delay completes. The Task returned by Task.Run (when you pass it an async delegate) is actually a "proxy Task" that represents the entire delegate.

is it possible to still use all the C# async language features (such as Task, 'await', 'async') on "regular" threads and not use the threadpool?

In your situation, you don't need it, but it is possible. My AsyncEx library includes an AsyncContextThread type that exposes a TaskFactory property you can use to start Tasks on that thread.

I'm servicing all instances "in parallel" using Task.Run()

In your case, you don't need Task.Run or a TaskFactory at all. You can easily do this in parallel without explicitly sending work off to the thread pool:

string[] instanceNames = ...;
var tasks = instanceNames.Select(ServiceInstanceAsync);
await Task.WhenAll(tasks);

private static async Task ServiceInstanceAsync(string name)
{
  await DownloadAndProcessFileAsync();
  await Task.Delay(15000);
  await ExecuteSSHAsync();
}
Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • thanks. your last section about "not needing Task.Run" intrigues me; unless there's a Task.Run inside those methods, or something that otherwise gets work running concurrently on another thread, how is the work getting done concurrently? – Michael Ray Lovett Nov 09 '12 at 00:21
  • Let me explain a bit more. In my case, I'm using an SSH library that is not async, but is thread safe. So I have created methods like GetFileAsync() which return a Task, and wrap up their SSH calls like this: "return Task.Run(()=> { ssh call }); – Michael Ray Lovett Nov 09 '12 at 00:23
  • So in my SSH case, it's pretty visible how work can get done concurrently. I could call my GetFileAsync multiple times in a row and each would launch a threadpool thread to do the work and return their Task immediately, which I can await. But without the call to Task.Run, my SSH methods would just be synchronous.. – Michael Ray Lovett Nov 09 '12 at 00:24
  • sorry to beat a dead horse, but I see lots of examples like yours where it's easy to see how "await" and "async" work, but that don't make it clear where/how work is getting concurrently done. I mean, if you follow any of the "...Async" methods down to the lowest level of code, somehow, somewhere, something is getting spun up on a separate thread, right? – Michael Ray Lovett Nov 09 '12 at 00:28
  • A lot of questions. :) I have an [intro to `async`/`await`](http://nitoprograms.blogspot.com/2012/02/async-and-await.html) on my blog that may help. ["Concurrent" does not necessarily mean "multithreaded"](http://stackoverflow.com/questions/7663101/c-sharp-5-async-await-is-it-concurrent). A `Task` is just a "future"; e.g., in the case of downloading files, no threads are spun up and blocked on the download - it's a threadless `Task` (similarly, `Task.Delay` is a threadless `Task`). – Stephen Cleary Nov 09 '12 at 00:39
  • So, in some cases (e.g., SSH), there is a `Task.Run`. But there are lots of cases where there isn't an explicit thread pool task. – Stephen Cleary Nov 09 '12 at 00:40
  • Sorry, that SO link should have been [to this question](http://stackoverflow.com/questions/10285159/difference-between-the-tpl-async-await-thread-handling) which has a better explanation of the difference between "concurrency" and "multithreading". – Stephen Cleary Nov 09 '12 at 00:48
  • thanks so much for your replies Stephen, especially for your confirmation that, in cases like my SSH case, of course I must start threads (ie Task.Run()) if I want concurrent SSH activity. Without my Task.Run(), I could use Tasks and "await" and "ascync" all day long and only end up with a non-concurrent solution. – Michael Ray Lovett Nov 09 '12 at 15:50
  • Your intro is wonderful. IMHO, I think your blog (and many other writings I've read) would benefit by spending more time exploring the questions of how we really end up with concurrent things happening in our code.. Async/await does not provide concurrency, it just provides a framework for dealing with concurrency elegantly. I.E, I could write a Task that just contains a bunch of math computations. But naming it "...Async" and "awaiting" it doesn't make the code run concurrently to anything.. it will run non-concurrently – Michael Ray Lovett Nov 09 '12 at 16:04
  • BTW, your link above was perfect, wish I'd come across this earlier :) – Michael Ray Lovett Nov 09 '12 at 16:11