What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Parallel Programming with .NET : What???s new in Beta 1 for the Task Parallel Library? (Part 2/3)

Wed, 15 Apr 2009 00:37:08 GMT

PingBack from http://blogs.msdn.com/pfxteam/archive/2009/04/06/9534426.aspx

Parallel Programming with .NET : What???s new in Beta 1 for the Task Parallel Library? (Part 1/3)

Wed, 15 Apr 2009 00:37:54 GMT

PingBack from http://blogs.msdn.com/pfxteam/archive/2009/03/27/9514938.aspx

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

aL — Wed, 15 Apr 2009 12:13:26 GMT

awsome stuff :) the ui scheduler and APM helpers will be a real production booster, as well as helping to reduce bugs :)

i have a question though,

is there any perticular reason why ContinueWhenAny/All takes a Task[] and not IEnumerable<Task>? (or maybe it does, its just that you used the ToArray method)

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

aL — Wed, 15 Apr 2009 12:19:36 GMT

On a related note, ContinueWhenAny/All would make great extension methods for IEnumerable<Task> :) any chance of that happening?

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Michael Cederberg — Wed, 15 Apr 2009 14:31:02 GMT

What is the algorithm for the default scheduler for creating new threads? Is it like the current .NET threadpool? Does it use the .NET threadpool?

Any thoughts on scheduling tasks on IO completion port threads (like WCF does)?

When replacing the default scheduler, how much of the underlying infrastructure is available (like local work stealing queues etc.)?

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

hyildiz — Thu, 16 Apr 2009 00:24:02 GMT

Michael,

Let me answer your questions in the order you asked:

TPL and .Net ThreadPool are now tightly integrated (TPL tasks run on TP worker threads, the most significant difference being how they can take advantage of the thread local work queues that enable work stealing). Given this, the policies for creating new threads for the default TPL task scheduler are exactly the same as the ThreadPool.

Currently we don't support scheduling tasks on IO completion port threads. Although we do provide the new FromAsync API set for creating tasks to wrap asynchronous operations. I'm not sure about the scenario you have in mind, but you probably want to check out the FromAsync methods. I should also note that they indirectly take advantage of the IO threadpool under the hood.

And about replacing the default scheduler. In summary the answer to your question is: No, none of the local workstealing queues structures are available for direct reuse in custom schedulers. But read on...

When you implement a custom scheduler, you need to implement all major blocks about that scheduler's functionality. This includes work queue structures, mangement of worker threads, and the dispatch loop itself. The reason we choose to go this way is because it enables a whole variety of application specific scheduling policies.

That being said, the interface b/w TPL runtime and the custom scheduler is laid out in such a way that, if the scheduler implementer decides to provide a local workqueue & workstealing enabled scheduler, then the portions of TPL that can take better advantage of local queues will continue to do so with their custom scheduler. Actually I'm specifically referring to task inlining behavior, which is used in various TPL codepaths involving waits. This can be enabled by a custom scheduler if it provides a proper implementation for the TaskScheduler.TryExecuteTaskInline() override.

Please let us know if you have further questions. Thanks.

-Huseyin Yildiz

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

toub — Thu, 16 Apr 2009 16:39:07 GMT

A few additional points, on top of Huseyin's excellent response:

- It is possible and relatively straightforward to implement a custom scheduler that schedules to the I/O ThreadPool, as WCF does. Once the Beta is out, we'll make sure to release a sample that shows how to do this, in case its important for your needs.

- We're also planning to release a sample that shows how to implement a work-stealing scheduler, in line with Huseyin's comments.

aL, regarding your questions:

- ContinueWhenAny/All are actually instance methods on the TaskFactory/TaskFactory<TResult> classes, so new, additional methods would be necessary to support them as extensions (which need to be static methods). You'll of course be able to add these easily on your own if you need them, just creating extension methods that delegate, e.g.

public static class MyExtensions

{

public static Task ContinueWhenAll(this IEnumerable<Task> tasks, Action<Task[]> continuationAction)

{

return Task.Factory.ContinueWhenAll(tasks.ToArray(), continuationAction);

}

...

}

- Regarding why these work with Task[] instead of IEnumerable<Task>, we went that route for consistency with existing APIs like WaitHandle.WaitAll. Additionally, we wanted consistency between WaitAll and WaitAny, and for WaitAny (which provides the index of the completed item), one needs to be able to index into the original set. From a usability perspective, do you value this kind of consistency? How important do you consider support for IEnumerable<Task> instead of Task[]?

Thanks.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

tobi — Thu, 16 Apr 2009 20:02:59 GMT

hi,

i would like to suggest that you concentrate your efforts more on features instead of performance and extensibility.

its nice that you can implement your own scheduler but who actually does that? there will probably be about 3-5 community driven and significant implementations of this. you dont need to provide a sample for that.

also, acceptance and usage will be driven by features and usability, not by performance as long as it is in a close range below optimal. please use your time to make coders more productive instead of investing 50% more work to achieve 10% perf improvement.

nevertheless i really enjoy using this library.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Michael Cederberg — Fri, 17 Apr 2009 11:43:32 GMT

The scenario for scheduling tasks on IOCP threads are:

We have a highly parallel server application than continuously have about 1000 tasks scheduled. We try keep CPU load at 100% (we have some heavy calculations that we would like to run continuously).

We currently have a very simple framework where we schedule tasks on IOCP threads (we plan to switch to TPL when it is released). When using the .NET ThreadPool we very easily end up with 1000 threads after running for some time (due to the .NET ThreadPool adding threads whenever there are queued workitems).

When using regular threads we can remedy the problem a bit, but we still end up having either way too many threads (utilizing too many resources and getting a lot of context switches) or too few threads (prune to deadlocks and less than optimal utilization of all CPUs whenever a task is waiting).

Scheduling tasks on IOCP threads provides better throughput in our scenario and is less prone to deadlocks than scheduling on regular threads (due to have way more IOCP threads ready for scheduling).

On a somewhat related note, now that you embrace the Asynchronous Programming Model, do you have any plans for asynchronous synchronization primitives (e.g. an asynchronous monitor or readerwriterlock)?

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

aL — Fri, 17 Apr 2009 16:41:43 GMT

hello, thanks for the reply :)

i dont have any perticular scenario where i have to have IEnumerable<Task> and not Task[] but i generally prefer ienumerable since it lazy :)

i do like consistency but if i'd rather have the exsisting apis also taking IEnumerables :)

however maybe it doesnt really matter that the arguments for ContinueWhenAny/All cant be lazily evaluated and there might be other side effects of this that i havent thought of :)

my main bother is that i have to write ToArray more, if they took ienumerables passing in Task[] would work anyway so from a callers prespective it would still be sort of consistent :)

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

tobi — Fri, 17 Apr 2009 21:37:38 GMT

what about taking middle ground in the debate about enumerables and Task[]. you said that you need to index into the collection that is passed in. so why dont you use IList<Task>? ie<Task> would always require you to internally call toList wasting cpu cycles.

i also doubt that i will ever see an ie<Task> that is supposed to be evaluated lazily. evaluation of an ie<T> is conceptually side-effect free like property getters are conceptually read-only operations. materializing tasks however is not side-effect free thereby violating intuition. also, the lazy evaluation immediately breaks down because the Wait-method has to evaluate the ie<Task> internally.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

tobi — Fri, 17 Apr 2009 21:48:36 GMT

also i'd like to hear a statement about scheduling io-heavy workloads or webservice-calls. the degree of parallelism is only weakly correlated with the number of cpu cores in this case. so the cpu-based scheduling will under or over utilize this resources. being able to specify the exact degree of parallelism conveniently will help a lot here.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

toub — Sat, 18 Apr 2009 19:59:32 GMT

Michael, thanks for the extra information. Regarding asynchronous locks (I'm assuming you mean something like http://msdn.microsoft.com/en-us/library/microsoft.ccr.core.interleave.aspx), it's definitely something we're investigating for the future, but we don't currently have plans to ship anything like that in .NET 4.

aL, thanks for the follow-ups on IEnumerable<Task>. We'll take a hard look at this and see if it's something that should be revamped.

tobi, thanks for the IList<Task> suggestion. Regarding always calling ToList internally, in effect we have to do that anyway, even if we're provided with an array. As we're dealing with concurrency, and as we need to work on the provided data concurrently with the thread that provided it to us, we need to make a defensive copy of the array/list/enumerable so that we can party on it without fear that after the call to us the code that called us will change the array. This enables that calling thread to reuse the array safely, without having to worry about additional lifetime and concurrency safety issues (at the expense, of course, of an allocation and copy).

Regarding your question around CPU vs I/O workloads, this is one of the reasons we've integrated so tightly with the .NET ThreadPool. The CLR team will be talking more about the work that's been done here for 4.0, but the ThreadPool has been augmented with new thread injection/retirement heuristics meant to very quickly ramp up to the optimal number of threads to maximize work item throughput. The limitation for this maximum is largely irrelevant to the ThreadPool, whether it's the number of CPUs or the bandwith of the network connection or disk throughput, etc. If you do want to place minimums and maximums, you can still use ThreadPool.SetMin/MaxThreads. And with the ability to write custom TaskSchedulers, you can also completely customize the scheduling logic to your hearts content. Your scheduler could use your own threads managed explicitly by your code, it could be built on top of the worker thread pool (simply layering additional logic on top of delegations to QueueUserWorkItem), it could be built on the I/O thread pool, etc.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

toub — Sat, 18 Apr 2009 20:28:34 GMT

Also, tobi, thanks for your suggestions on priorities, and I'm glad you enjoy using the library; I hope that when the Beta comes out, you're excited about the features it offers. Please let us know at that point if there's something specific and high-value to you that you see it missing.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

aL — Sun, 19 Apr 2009 02:20:03 GMT

glad to provide food for thought :) im by no means an expert though so i might be totaly wrong..

one way to get around indexing might by to have WaitAny provide the actual task and not the index :) but perhaps a change like that would break alot of exsisting code

lazy eval might not be the best thing (again, im no expert) but it would seem you'd be able to save allocations in wait/continueWhenAny if lets say the first task out of 1000 immedietly finishes, they you wouldnt even need to instansiate the other 999 :)

also, i've heard that ie<T> promotes shorter object lifetimes and that that is beneficial for garbage collection. i might be wrong about that though

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Tamer — Wed, 29 Apr 2009 20:18:42 GMT

Is there a timeline for the release of Beta1? (either for TPL or .net 4.0) ?

What’s new in Beta 1 for Parallel LINQ (PLINQ)?

Parallel Programming with .NET — Wed, 29 Apr 2009 21:56:16 GMT

A number of improvements have been made to Parallel Extensions since the Visual Studio 2010 CTP across

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style — Wed, 29 Apr 2009 22:52:09 GMT

PingBack from http://www.codedstyle.com/what%e2%80%99s-new-in-beta-1-for-parallel-linq-plinq-2/

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style — Wed, 29 Apr 2009 22:52:49 GMT

PingBack from http://www.codedstyle.com/what%e2%80%99s-new-in-beta-1-for-parallel-linq-plinq-4/

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

dashih — Thu, 30 Apr 2009 01:30:28 GMT

Tamer, we cannot make any statements about the Beta 1 schedule at this time. Very sorry!

aL, we considered returning the actual Task instead of an index from WaitAny. However, that would make the following scenario more difficult. Let's say that you wanted to manipulate an array of Tasks after passing it to WaitAny - maybe remove the Task that WaitAny returned. If the actual Task was returned, you'd have to walk the array searching for that Task. With an index, you could access it immediately.

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

aL — Fri, 01 May 2009 02:28:29 GMT

true.. :) but that seems like a slightly odd thing to do, you cant even remove stuff from arrays anyways, you could only set it to null or something.. it seems more likely that you'd be interested in the result of the task that finished (if you're interested in the task at all) and then you'd have to dereference the array to get it.. not to mention that you have to have accress (scope wise) to the original array, something that would promote shared state..

i still think lazy would be the better way to go, esp. considering cancelation :) it seems you would materialize alot more tasks that you dont have to materialize when you have arrays beeing passed around :)

i cant wait to until the beta comes out and the stuff you're doing are really awsome :) but from my point of view the arrays seem like a mistake :)

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Tamer Yousef — Fri, 01 May 2009 20:01:54 GMT

got a question, is there a way to know when a task started? I'm looking for somthing like:

Task.StartedAt as dateTime

Task.FinishedAt as dateTime

it will really help to collect some performance information about tasks. right now I collect the task finished datetime with the use of ContinueWith, but I'm not sure how to get the started dateTime, it would be nice if it's part of the Task class itself.

thanks!

-Tamer

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Tamer Yousef — Fri, 01 May 2009 21:57:35 GMT

the way I'm doing it now is by setting the start and finished datetime from inside the task (inside the delegate) and I'm saving references to all delegates in an array that have the same index as the task array, then I iterate throught the two arrays to grab the task status and the delegate information.

It's not the best way to do it but the only way I'm aware of.

-Tamer

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

toub — Sat, 02 May 2009 05:08:25 GMT

Hi Tamer-

It's not something we do automatically. While it could be useful for certain niche situations, there's a non-negligable cost to accessing timing information, and it's not something we're keen to incur, especially since most scenarios don't need this information.

If your goal is to time the actual body of the task, your best bet is to embed the start and stop calculation into the body of the task, using System.Diagnostics.Stopwatch or something similar. If you use a continuation to track the end, you'll also be measuring the overhead in TPL for completing one task and running the following continuation. Similarly, if you start the stopwatch prior to creating and starting the task, you'll be measuring the overhead associated with those operations and not just the body.

Any plans to integrate with .Net 3.5 Async Sockets?

Sam Leitch — Thu, 07 May 2009 07:11:34 GMT

.Net 3.5 introduced a new method of interacting with Sockets asynchronously, which improved the performance over its begin/end counterpart. Are there any plans to integrate that into the TPL similar to the FromAsync method?

I actually like the async event object model better than the begin/end model and would love to see it used more.

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style

What???s new in Beta 1 for Parallel LINQ (PLINQ)? | Coded Style — Thu, 07 May 2009 22:55:08 GMT

PingBack from http://www.codedstyle.com/what%e2%80%99s-new-in-beta-1-for-parallel-linq-plinq/

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Joe — Fri, 15 May 2009 09:14:52 GMT

You say that the ContinueWith method on Task enables a slew of powerful patterns. Can you give a quick overview of these patterns?

Parallel Tasks � new VS2010 debugger window

Daniel Moth — Fri, 15 May 2009 13:05:19 GMT

Parallel Tasks � new Visual Studio 2010 debugger window

MSDN Flash Podcast Pilot Show 2 for May 6th 2009

IUpdateable from Eric Nelson — Mon, 18 May 2009 20:56:37 GMT

This is the second pilot podcast to accompany the fortnightly MSDN Flash newsletter (Check out Pilot

MSDN Flash Podcast Pilot Show 2 for May 6th 2009

Testing Blog Loc - Japanese — Mon, 18 May 2009 22:00:13 GMT

This is the second pilot podcast to accompany the fortnightly MSDN Flash newsletter (Check out Pilot

.NET 4 Beta 1 is now available, with parallelism!

Parallel Programming with .NET — Thu, 21 May 2009 01:39:00 GMT

We’re very excited that the .NET Framework 4 Beta is now available for public download, as .NET 4 has

.NET 4 Beta 1 is now available, with parallelism! | Coded Style

.NET 4 Beta 1 is now available, with parallelism! | Coded Style — Thu, 21 May 2009 02:46:17 GMT

PingBack from http://www.codedstyle.com/net-4-beta-1-is-now-available-with-parallelism/

Visual Studio 2010 Beta 1 est disponible pour tous !!!

Développement parallèle — Thu, 21 May 2009 13:21:08 GMT

Mots clés Technorati : Visual Studio 2010 , PFX , Concurrency Runtime , TPL , PLINQ , Exemples , Documentation

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

dashih — Fri, 22 May 2009 03:56:22 GMT

Joe,

Re: overview of ContinueWith patterns

We'll be posting something about this in the near future.

Thanks for your interest!

MSDN Flash Podcast Pilot Show 2 for May 6th 2009 | Coded Style

MSDN Flash Podcast Pilot Show 2 for May 6th 2009 | Coded Style — Sat, 23 May 2009 20:40:57 GMT

PingBack from http://www.codedstyle.com/msdn-flash-podcast-pilot-show-2-for-may-6th-2009/

.NET 4 Beta 1 is now available, with parallelism! | Coded Style

.NET 4 Beta 1 is now available, with parallelism! | Coded Style — Wed, 27 May 2009 02:22:55 GMT

PingBack from http://www.codedstyle.com/net-4-beta-1-is-now-available-with-parallelism-2/

Visual Studio 2010 Beta 1 est disponible pour tous !!! | Coded Style

Visual Studio 2010 Beta 1 est disponible pour tous !!! | Coded Style — Wed, 27 May 2009 02:59:36 GMT

PingBack from http://www.codedstyle.com/visual-studio-2010-beta-1-est-disponible-pour-tous-2/

Parallel Programming with NET What s new in Beta 1 for the Task | Cellulite Creams

Tue, 09 Jun 2009 06:17:57 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=4277

re: What’s new in Beta 1 for the Task Parallel Library? (Part 3/3)

Philip — Mon, 15 Jun 2009 17:09:52 GMT

As a follow up to the Task[] params, After a bit of use I find that I *always* have something that implements IEnumerable<Task> and have *never* had an array, so I end up calling toarray every time. While this isn't a huge problem, my code would be cleaner if there were a way to pass IEnumerable<Task> or IList<Task> directly - IList<Task> covers almost all of the scenarios as well.