i3arnon’s answer with TPL Dataflow is good; Dataflow is useful especially if you have a mix of CPU and I/O bound code. I’ll echo his sentiment that Parallel is designed for CPU-bound code; it’s not the best solution for I/O-based code, and especially not appropriate for asynchronous code. If you want an alternative solution that … Read more
I’ve discovered that TaskCompletionSource.SetResult(); invokes the code awaiting the task before returning. In my case that result in a deadlock. Yes, I have a blog post documenting this (AFAIK it’s not documented on MSDN). The deadlock happens because of two things: There’s a mixture of async and blocking code (i.e., an async method is calling … Read more
RegisterWaitForSingleObject will combine waits onto dedicated waiter threads, each of which can wait on multiple handles (specifically, 63 of them, which is MAXIMUM_WAIT_OBJECTS minus one for a “control” handle). So you should be able to use something like this (warning: untested): public static class WaitHandleExtensions { public static Task AsTask(this WaitHandle handle) { return AsTask(handle, … Read more
I think the current behavior makes sense. If I create my own task scheduler, and start some task that starts other tasks, I probably want all the tasks to use the scheduler I created. I agree that it’s odd that sometimes starting a task from the UI thread uses the default scheduler and sometimes not. … Read more
var t = new Task<int>(() => GetIntAsync(“3”).Result); Or var t = new Task<int>((ob) => GetIntAsync((string) ob).Result, “3”); To avoid using lambda, you need to write a static method like this: private static int GetInt(object state) { return GetIntAsync(((string) state)).Result; } And then: var t = new Task<int>(GetInt, “3”);
While the normal rule of thumb is to always call Dispose() on all IDisposable implementations, Task and Task<T> are often one case where it’s better to let the finalizer take care of this. The reason Task implements IDisposable is mainly due to an internal WaitHandle. This is required to allow task continuations to work properly, … Read more
You must not start the parallel processing in your UI thread. See the example under the “Avoid Executing Parallel Loops on the UI Thread” header in this page. Update: Or, you can simply create a new thread manuall and start the processing inside that as I see you have done. There’s nothing wrong with that … Read more
The newest version of .Net (v4.6) is adding just that, a built-in Task.CompletedTask: Task completedTask = Task.CompletedTask; That property is implemented as a no-lock singleton so you would almost always be using the same completed task.
By using code from this article, you can implement the following: public static Task<Task<T>>[] Interleaved<T>(IEnumerable<Task<T>> tasks) { var inputTasks = tasks.ToList(); var buckets = new TaskCompletionSource<Task<T>>[inputTasks.Count]; var results = new Task<Task<T>>[buckets.Length]; for (int i = 0; i < buckets.Length; i++) { buckets[i] = new TaskCompletionSource<Task<T>>(); results[i] = buckets[i].Task; } int nextTaskIndex = -1; Action<Task<T>> continuation … Read more
Here is a RateLimiter class that you could use in order to limit the frequency of the asynchronous operations. It is a simpler implementation of the RateLimiter class that is found in this answer. /// <summary> /// Limits the number of workers that can access a resource, during the specified /// time span. /// </summary> … Read more