Is it possible to reuse the same Task<T> created with Task.FromResult for instant returning methods (as it is completed already anyway)?
My reasoning behind the question is to reduce garbage produced by implementations of async interfaces that complete instantly (Task<bool> would be a great example for it, as it only has two possible values).
Base on this article about disposing of tasks, it should be possible, if .NET Core behaves the same (does it?).
Yes, and this is actually strongly recommended in cases where you have a small set of likely results that might be known synchronously (from cache, etc). Likewise, in the case of Task (not Task<T>), Task.CompletedTask can be used.
Note that if most of your calls complete synchronously but you do not have a small domain of likely results, you might want to consider ValueTask<T>, which is optimized for this case.
Everything here applies equally to both .NET and .NET Core.
Related
In this article: https://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html , it is advised against using Task.Run. however there are lot of libraries that provide methods that ends with Async and hence I expect those methods to return a running task that I can await (which however is not necessary, since those libraries could decide to return a synchronous task).
The context is a ASP.NET application. How am I supposed to make a method running in parallel?
What I understand is that async calls are executed in parallel if they contain at least one "await" operator inside, the problem is that the innermost call, should be parallel to achieve that, and to do that I have somewhat to resort to Task.Run
I have also seen some examples using TaskCompletionSource, is this necessary to implement the "inner most async method" to run a method in parallel in a ASP.NET application?
In an ASP.Net application we tend to value requests/s over individual response times1 - certainly if we're directly trading off one versus the other. So we don't try to focus more CPU power at satisfying one request.
And really, focussing more CPU power at a task is what Task.Run is for - it's for when you have a distinct chunk of work to be done, you can't do it on the current thread (because its got its own work to do) and when you're free to use as much CPU as possible.
In ASP.Net, where async shines is when we're dealing with I/O. Nasty slow things like accessing the file system or talking to a database across the network. And wonderfully, at the lowest level, the windows I/O system is async already and we don't have to devote a thread just to waiting for things to finish.
So, you won't be using Task.Run. Instead you'll be looking for I/O related objects that expose Async methods. And those methods themselves will not, as above, be using Task.Run. What this does allow us to do is to stop using any threads for servicing our particular request whilst there's no work to be done, and so improve out requests/s metric.
1This is a generalization but single user/request ASP.Net sites are rare in my experience.
I have a lot of Utils classes that I use for many different projects, most of them are static and made out of static methods that usually don't even call each others.
My intention is to take advantages from the new async/await features but without rewriting everything, so my question is: can I just add a new method for each existing method named MethodAsync with the Task.Run(() => MethodName)?
example:
//old code that will not be removed
static void DoSomething()
{ ... }
//new code that will be added
static async Task DoSomethingAsync()
{
//not really sure if Im supposed to use await/async here.
//isn't Task awaitable even without async??
return await Task.Run(() => DoSomething());
}
Basically in the old code I just had a normal sync method while in the new one I have an async method that could even run in another thread if the CLR see it as a CPU-bound method.
If I correctly understand, every asyncronous method contains by definition an await to an awaitable object which is a Task or another asyncronous method.
that means that whenever I can use an async .NET method, I should await it and mark my caller method as async.
But, every other method that do not call any async method but could take some time to complete should be called with a Task.Run call.
right?
EDIT
so I have read all the posted links, the best practices on msdn and a few blog posts but I still need a complete routine to follow when coding with the new async/await feature.
this is what I get so far:
1) every .NET method that has an async alternative should use the async alternative. (As far as I know the .NET async methods already exists ONLY for methods that can be async).
2) every method that use async methods should be made async too.
3) every method that do not use async methods (cause there aren't available) but still takes some cpu-time to execute should be made async by wrapping them using Task.Run (I understand that in this case it should be the client to use Task.Run if they want but since im only adding these wrappers for methods that takes more than 50ms to execute and there will be still available the non-async version of the method, I still don't see why I shouldn't place this wrapper in the library).
4) every method that takes non-cpu-time cause it's waiting for other sources (like internet, database, events, etc...) should use TaskFactory.FromAsync or TaskCompletionSource.
5) System.Threading.Tasks.Parallel.Invoke(method1, method2, etc...) is now deprecated. From what I read Task.Run already run concurrent threads if the CLR thinks that concurrency is required. So it seems that Task.Run already uses Parallel.Invoke when needed.
I was finally able to find good resources that cleared all my doubts:
the first one is "The Task-based Asynchronous Pattern" available at http://www.microsoft.com/en-us/download/details.aspx?id=19957
This document explains the async/await feature, how/when to use it, it contains many practical examples and a few of very usefull static methods that im now using on every project!
The second one is "The zen of async: Best practices for best performance" available at http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-829T
which is a complete overview of the async feature, with some coverage of the Parallel features and it also explains why it should never be the library that use Task.Run() method but it should be a consumer choice instead.
So in the end I was really confusing multithreading with asynchronous code and I couldn't grasp the advantages of async code because I was just looking at 1 single method at the time while the real benefits of async code can only be seen if the entire project (or at least a consistent portion of it) is written following the async pattern.
For example in asp.net, if there isn't any blocking code (everything written in a async fashion way), then a thread can serve another client while yours is awaiting an async operation, improving scalability, while in a xaml application a thread that launch an async operation can immediately go back to supporting your UI instead of just waiting that operation to be over, improving responsiveness.
This has been discussed in Should I expose asynchronous wrappers for synchronous methods? The part of this article that I thought highlighted why this is bad design is below:
Consider, for example, a simple method like Dictionary<TKey,TValue>.Add(TKey,TValue). This is a really fast method, right? Typically, yes, but remember how dictionary works: it needs to hash the key in order to find the right bucket to put it into, and it needs to check for equality of the key with other entries already in the bucket. Those hashing and equality checks can result in calls to user code, and who knows what those operations do or how long they take. Should every method on dictionary have an asynchronous wrapper exposed? That’s obviously an extreme example, but there are simpler ones, like Regex. The complexity of the regular expression pattern provided to Regex as well as the nature and size of the input string can have significant impact on the running time of matching with Regex, so much so that Regex now supports optional timeouts… should every method on Regex have an asynchronous equivalent? I really hope not.
Obviously I advise you to read the entire article too, but I hope the above highlights a great reason why exposing *Async() methods should not wrap synchronous ones in a library.
I hope this helps.
I have a bunch of interfaces for a repository in a core class library that defines return types as Task. These interfaces are used in other projects to define async methods.
I need to implement these same interfaces in a Xamarain monodroid project and was wondering how I should use the same return types without using async await since that's not supported yet in MonoDroid. I don't want to modify the existing core library interfaces at all if possible.
Technically, you don't have to use async/await; it's just a lot easier than doing it "by hand". Your implementations just have to return Tasks that are never null and already started (if applicable).
The TAP document has some useful techniques and guidelines. One key type is TaskCompletionSource<TResult> which you can use to wrap any asynchronous implementation (e.g., APM). Synchronous implementations can use Task.FromResult (which is just a small wrapper around TaskCompletionSource. If you have CPU work to do, you can use Task.Factory.StartNew, which is closely related but not quite equivalent to Task.Run. For more complex implementations, you would need continuations a la ContinueWith.
In other words, all the .NET 4.0 TPL techniques can be used, as long as your returned Tasks are always started. (The only way to get an unstarted Task is to construct it with the Task constructor and not call Start. So as long as you don't do this, you should be fine.)
So the new async CTP is very cool; it makes my life a lot easier not having to write named callback methods and makes the intent of the methods a lot clearer.
Now that I've gotten to play with it a little, I'm wondering what differences there may be between the async/await and the "classic" asynchronous callback syntaxes.
Here are a few questions I have in mind, but there are numerous others that I won't have thought of now and probably will later.
Does one perhaps offer superior performance over the other?
Is there an overhead to one that is greater than the other?
Which would be better to use in a high-performance environment?
The answer is complicated, the current compiler implementation of await is in several ways better than callbacks, but in some cases worse.
.NET Execution Context: We intend for both await and ContinueWith(...) capture and restore .NET Execution Context. It wouldn't pass .NET safety requirements otherwise, because then you'd be able to take arbitrary things like credentials, etc. and leave them on the threadpool for the next workitem. For 'await', this is an adjustment we made in the internal builds, but it was after we produced the //BUILD developer preview.
Memory Allocations: In several ways 'await' is better on memory allocations than manual callbacks. The key is that for functions with many awaits, what you're really generating is the equivalent of several callbacks. If you have 5 awaits in linear execution order, and with execution always flowing to the end, then the equivalent would require 5 callbacks. For each of those 5 callbacks, it's possible to generate a separate lambda closure object and a delegate that represents that specific lambda. In the 'await' case, the compiler knows that you're not going to use the delegate object for anything else. So instead, the entire method shares 1 closure and 1 delegate, with an internal state machine to keep track of where you are inside the method. Thus, for this case, 'await' allocates fewer objects, which actually can speed up your program since too many objects = more time the GC has to spend figuring out what's alive/dead.
Short-cutting 'Await' also has fancier semantics than just callbacks. In the case where you are creating a callback lambda, the compiler is forced to allocate the closure and the lambda's entrypoint delegate no matter what. For 'await', the await contract allows for a more optimized codepath for awaitables that are already "done". if the awaitable says it's "done" before the await gets evaluated, the semantic is just a pure pass-through of yanking out the result. This means that there's an opportunity for the compiler to delay allocation until you really need it, and thus you never pay the closure allocation, delegate allocation, nor scheduling cost, unless you actually need it. The current Developer Preview compiler includes these performance optimizations.
Trading danger for perf If you really want to bypass the .NET security model, you could kind of imagine a case where you can get a little bit of perf by avoiding the execution context package/restore, if you are absolutely confident that you will never need to capture/restore context. However, most of .NET's methods will do that silently under the covers, so you really need to know which ones will give you raw access without it. The rule of thumb for .NET is that if the API is available in partial trust (e.g. Silverlight), then the API certainly captures context when invoked, and then restores it, if it's an API that tranfers execution elsewhere (e.g. ContinueWith, QueueUserWorkItem(...), etc.). If you roll your own threadpool that just queues up delegates, you can bypass this, but most likely you don't need it.
My personal recommendation Use await. It's higher level, and it's what you want. We've put in a fair amount of effort trying to tune it for this release, and we could probably tune it further. Callback-based APIs will be more limiting, because the compiler can only tune so much before they start breaking the language rules. Awaits in a method allow for you to have smarter closures than callbacks. AND... await is a lot more intuitive to read/use than callbacks :)
Like anonymous functions and iterators, the async and await keywords are syntactic sugar. In a technical sense, they are no more or less efficient than the equivalent non-sugary versions. They just save you a lot of typing.
Recently I stumbled across the AsyncEnumerator class form Jeffrey Richter's Power Threading Library which seems to solve several problems I'm usually encountering when programming asynchronous stuff.
The idea for this class has been around for quite a while now and I'm wondering if current versions of .NET / C# have built-in support for this mechanism by now or if it is still necessary to rely on a third party library? Or maybe newer versions of .NET have some alternative approach which simplifies asynchronous programming as much as Richter's AsyncEnumerator does?
Or in other words: Is there a reason to not start using Richter's AsyncEnumerator today?
Edit:
Some links with information on AsyncEnumerator:
Jeffrey Richter and his AsyncEnumerator
Simplified APM With The AsyncEnumerator
More AsyncEnumerator Features
Yes, you will still benefit from my AsyncEnumerator. The new threading stuff introduced in .NET 4 (Tasks, Parallel, PLINQ, etc), is all about concurrency. That is, they are all about taking a computational workload, dividing it up and spawning it out onto multiple threads so that the workload can complete in less time than it would takes 1 thread to do the entire workload. You can use these constructs to execute multiple synchronous I/O operations concurrently. However, the synchronous I/O operations cause all the threads to block which then causes the threadpool to create more threads. And so, your app's resource usage skyrockets while your CPU usage remains very low. This is a very inefficient to implement your application and prevents your app from scaling.
My AsyncEnumerator is all about initiating asynchronous I/O operations without blocking any threads so that your app's resource usage remains very low so your app scales very well. CPU usage remains low in this case too because you are performing I/O; not a computational workload.
In the next version of .NET, the new async/await language features (which I worked on with Microsoft), enables you to perform async I/O and in fact, the new features are modeled very similar to my AsyncEnumerator. So much so that you can port code that uses my AsyncEnumerator to the new model with very few source code changes.
As someone else pointed out, my AsyncEnumerator still offers other features and works with .NET 2.0 and later. So, many people will still find it quite useful for a long time.
An obvious parallel here is PLINQ, but Richter himself dismisses this:
Jeffrey Richter Dec 04, 2008 at 2:27 PMquotereply They are very
different. Parallel.For in particular is about performing a bunch of
compute-bound operations in parallel scaling out across all the CPUs
in teh machine. My AsyncEnumerator is mostly about issuing one or more
concurrent I/O-bound operations without have any threads block for
them to complete.
However, the C# async CTP may be useful here, making thread continuations much more reasonable, i.e.
var bytesRead = await stream.ReadAsync(...);
Console.WriteLine(bytesRead); // woah! we're on a different thread now!
Here, the C# compiler re-writes everything around await instuctions, such that it becomes a callback/continuation to the existing async operation (which must return an "awaitable" value). Once this is in production, I hope this will become a much more natural way to write code with intrinsic delays due to async.
.net 4.0 includes the PLINQ framework and various other means of threaded computation.
See Parallel Programming in the .NET Framework for more details.
From this question Asynchronous iterator Task<IEnumerable<T>> :
It sounds like what you may really be looking for is something like IObservable<T>, which is sort of like a push-based asynchronous IEnumerable<T>. See Reactive Extensions, a.k.a. Rx from Microsoft Open Technologies (code licensed under Apache-2.0) (no affiliation) for a huge host of methods that work with IObservable<T> to make it work like LINQ-to-Objects and more.
The problem with IEnumerable<T> is that there's nothing that really makes the enumeration itself asynchronous. If you don't want to add a dependency on Rx (which is really what makes IObservable<T> shine), this alternative might work for you:
public async Task<IEnumerable<char>> TestAsync(string testString)
{
return GetChars(testString);
}
private static IEnumerable<char> GetChars(string testString)
{
foreach (char c in testString.ToCharArray())
{
// do other work
yield return c;
}
}
though I'd like to point out that without knowing what's **actually being done asynchronously, there may be a much better way to accomplish your goals. None of the code you posted will actually do anything asynchronously, and I don't really know if anything in // do other work is asynchronous (in which case, this isn't a solution to your underlying problem though it will make your code compile).