locked
Specifying TaskCreationOptions in CTP TaskEx methods

    Question

  • Hey, I was wondering if anyone could help me with a question I'm having.

    I'm planning to design a large system that I feel will really benefit from these new language features, and certain convenience methods currently offered in TaskEx. My question is this:

    Is it likely that the convenience methods (such as TaskEx.Delay) that ultimately instantiate Tasks and return them, in the final release, will contain overloads where we can specify TaskCreationOptions ? I am also curious if this will be possible for anything where the TPL automatically creates the Task object it returns to you.

    If not, is there some way to set this after the instantiation of the Task object that I'm unaware of (it seems unlikely, by the "Creation" part of the name)? I am still somewhat new to the TPL; I see the ability to specify TaskCreationOptions, (particularly the LongRunning value) as something that would be beneficial to the performance of my system.

    Thanks


    Wednesday, April 25, 2012 6:11 AM

Answers

  • You're right that when you write async method, the Task is created for you automatically.

    But if you have an async method that runs long, because it's awaiting something (like downloading a big file), then it doesn't use any threads while it's waiting. So if you could somehow specify to create a new Thread for this method, that would be less efficient.

    If you have an async method that is long running because it performs some synchronous operation (CPU-bound computation, or some operation that doesn't have asynchronous version), then it might make sense to run the synchronous part in its own LongRunning Task. Or you could run the whole method in a LongRunning Task, without using async at all. But I think doing this would be more performant only in rare cases.

    But I still think it doesn't make sense to use LongRunning for async methods, like you suggested, because the point of async methods is that they don't use any Threads while waiting. I don't see how would LongRunning help there, it would only make matters worse.

    Could you describe what exactly would your Task do? Why do you think having a dedicated Thread for it would help you?

    • Marked as answer by Nick Trombetta Wednesday, April 25, 2012 6:54 PM
    Wednesday, April 25, 2012 6:26 PM

All replies

  • Overloads that accept TaskCreationOptions for those methods aren't available in .Net 4.5 beta (see for example the documentation for Task.Delay()).

    I think the reason for this is that it doesn't make any sense. The Task that is returned from Task.Delay() doesn't actually execute, so it doesn't make any sense to specify that it's LongRunning or PreferFairness.

    For “normal” Tasks, the effect of LongRunning is that it creates a new Thread for this Task and doesn't consume a ThreadPool thread. But this doesn't make any sense for the Tasks you're talking about, because they don't use Threads at all.

    How do you think it would “be beneficial to the performance of my system”? What do you think it should do?

    Wednesday, April 25, 2012 10:02 AM
  • Thanks for your response. 

    The reason why I thought it might be beneficial to the performance of my system is precisely because of what you said about the effects of LongRunning. I am planning on having a task that ought to have its own Thread due to the fact that it will be long running. However, this Task has nothing to do with Delay; rather, this Task is a "normal" task, not one that would be returned by a method in the framework. I guess the source of my confusion is this:

    Is it the case that async methods, when they return a Task or a Task<T>, automatically create Task objects for you? If so, this is where I am curious if we would be able to specify the TaskCreationOptions. In a tutorial video I watched recently, it was mentioned that even though an async method returns, say, Task<string>, in the method body, I could write return "Some String", and the compiler would wrap all of the preceding async logic along with the returned value in the Task for you. 


    Wednesday, April 25, 2012 5:55 PM
  • You're right that when you write async method, the Task is created for you automatically.

    But if you have an async method that runs long, because it's awaiting something (like downloading a big file), then it doesn't use any threads while it's waiting. So if you could somehow specify to create a new Thread for this method, that would be less efficient.

    If you have an async method that is long running because it performs some synchronous operation (CPU-bound computation, or some operation that doesn't have asynchronous version), then it might make sense to run the synchronous part in its own LongRunning Task. Or you could run the whole method in a LongRunning Task, without using async at all. But I think doing this would be more performant only in rare cases.

    But I still think it doesn't make sense to use LongRunning for async methods, like you suggested, because the point of async methods is that they don't use any Threads while waiting. I don't see how would LongRunning help there, it would only make matters worse.

    Could you describe what exactly would your Task do? Why do you think having a dedicated Thread for it would help you?

    • Marked as answer by Nick Trombetta Wednesday, April 25, 2012 6:54 PM
    Wednesday, April 25, 2012 6:26 PM
  • Thank you, that response was exactly the clarification I needed. I guess I didn't understand completely when to use async methods and when to run the method in a Task without using async.

    P.S.  I have been watching some videos of your talks at PDC, and I just want to say, they have been very informative and useful. 

    Wednesday, April 25, 2012 6:54 PM