Related Posts:<\/p>\n
Last week we talked about changes under the covers, redesigns in System.Threading.Parallel, and using CancellationTokens. <\/span>So what else is new in TPL for Beta 1? <\/span>In this post, we’ll cover the new TaskFactory<\/b> class, the plight of Future<T> (Task<TResult><\/b>), and TaskCompletionSource<TResult><\/b>.<\/font><\/p>\n There are two ways to create and schedule Tasks: use constructors and instance methods, or use static methods like StartNew. <\/span>In previous releases, these two functionalities were jammed into the Task class, and we realized that separating them would result in a cleaner design. <\/span>So we introduced the TaskFactory class, which contains all static methods that create and\/or schedule Tasks. <\/span>In Beta 1, these static methods include more than just StartNew, but those will be covered in the next post!<\/font><\/p>\n For convenience, Task now contains a static Factory property which returns a default instance of TaskFactory. <\/span>So for many users, the biggest practical difference is that where you would have used Task.StartNew (or Task.Create in the June 2008 CTP and earlier), you now use:<\/font><\/p>\n Task.Factory.StartNew(() =><\/p>\n <\/span><\/p>\n {<\/p>\n <\/span><\/p>\n <\/span>… <\/span><\/p>\n <\/p>\n <\/p>\n <\/span><\/p>\n An additional advantage of TaskFactory is the ability to consolidate the specifying of options such as creation options, continuation options, and which scheduler to use:<\/font><\/p>\n <\/font><\/p>\n<\/p>\n TaskFactory myFactory = new<\/span> TaskFactory(<\/p>\n <\/span><\/p>\n <\/span>myScheduler, myCreationOptions, myContinuationOptions);<\/p>\n <\/span><\/p>\n <\/p>\n <\/p>\n <\/span><\/p>\n Task t0 = myFactory.StartNew(() => { });<\/p>\n <\/span><\/p>\n Task t1 = myFactory.StartNew(() => { });<\/p>\n <\/span><\/p>\n Task t2 = myFactory.StartNew(() => { });<\/p>\n <\/span><\/p>\n <\/p>\n In previous releases, Tasks that produced results were called Futures. <\/span>Moving forward, we’ve opted to rename Future<T> to Task<TResult>, a type that derives from Task. <\/span>There were a number of reasons, including:<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>We constantly found ourselves describing Futures as “tasks that return results”.<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>Many folks, that we spoke with, found the name Task<TResult> clearer.<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>There is some discrepancy in literature and concurrency circles about exactly what’s implied by the term “future” (What functionality should or should not be exposed? <\/span>Side-effect free?)<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>The name Future has a not-related-to-Task implication. <\/span>However, we wanted Task<TResult> to derive from Task so that the former could be treated polymorphically as the latter. <\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>We wanted TaskFactory methods to be able to return “tasks that return results”. <\/span>For example, it would have been odd for Task.Factory.StartNew to return a Future.<\/font><\/p>\n A Task<TResult> is typically used to asynchronously execute a delegate that computes and returns a result. <\/span>Sometimes however, the asynchronous operation cannot be represented by a delegate, but rather is performed by an external entity.<\/font><\/p>\n Such functionality was originally supported on Future<T>, via a special constructor that did not take a delegate. <\/span>A Future created this way could have its Value or Exception properties set using the respective setters. <\/span>There were several problems with this approach, for example:<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>The setters were only usable if the Future<T> was created with the special constructor.<\/font><\/p>\n ·<\/font> <\/span><\/span><\/span>Commonly, a producer would want to hand out a Future<T> to consumers, but not allow the consumers to resolve it. <\/span>However, in this scheme, anyone who had a reference to the Future<T> could resolve it.<\/font><\/p>\n We’ve addressed these issues by introducing a new TaskCompletionSource<TResult> type:<\/font><\/p>\n <\/p>\n <\/span><\/p>\n TaskCompletionSource<int> tcs = new TaskCompletionSource<int>();<\/p>\n <\/span><\/p>\n Task<int> task = tcs.Task;<\/p>\n <\/span><\/p>\n <\/p>\n <\/p>\n <\/span><\/p>\n \/\/ Sometime later…<\/p>\n <\/span><\/p>\n tcs.SetResult(computedResult); <\/span>\/\/ Or tcs.SetException(exc), or tcs.SetCanceled()<\/p>\n <\/span><\/p>\n <\/p>\n <\/p>\n <\/span><\/p>\n \/\/ In a consumer elsewhere…<\/p>\n <\/span><\/p>\n try { Console.WriteLine(task.Result); }<\/p>\n <\/span><\/p>\n catch (AggregateException ae) { }<\/span><\/p>\n <\/span><\/p>\n \n <\/font><\/p>\n<\/p>\n In this post, we covered the most fundamental redesigns to TPL tasks. <\/span>“What’s new in Beta 1 for TPL (Part 3\/3)” will cover all remaining changes, such as other helper methods on TaskFactory and the new TaskScheduler. <\/span>Look forward to it!<\/font><\/p><\/p>\n","protected":false},"excerpt":{"rendered":" Related Posts: What’s new in Beta 1 for the Task Parallel Library? (Part 1\/3) What’s new in Beta 1 for the Task Parallel Library? (Part 3\/3) Last week we talked about changes under the covers, redesigns in System.Threading.Parallel, and using CancellationTokens. So what else is new in TPL for Beta 1? In this post, we’ll […]<\/p>\n","protected":false},"author":485,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[],"class_list":["post-2233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam"],"acf":[],"blog_post_summary":" Related Posts: What’s new in Beta 1 for the Task Parallel Library? (Part 1\/3) What’s new in Beta 1 for the Task Parallel Library? (Part 3\/3) Last week we talked about changes under the covers, redesigns in System.Threading.Parallel, and using CancellationTokens. So what else is new in TPL for Beta 1? In this post, we’ll […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/485"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=2233"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2233\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=2233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=2233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=2233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}TaskFactory<\/font><\/h2>\n
});<\/p>\nTask<TResult><\/font><\/h2>\n
TaskCompletionSource<TResult><\/font><\/h2>\n