Sorted By: Tag (tpl)

Should I await on Task.FromResult Method Calls?

Task class has a static method called FromResult which returns an already completed (at the RanToCompletion status) Task object. I have seen a few developers "await"ing on Task.FromResult method call and this clearly indicates that there is a misunderstanding here. I'm hoping to clear the air a bit with this post.
2014-02-24 21:14
Tugberk Ugurlu


Task class has a static method called FromResult which returns an already completed (at the RanToCompletion status) Task object. I have seen a few developers "await"ing on Task.FromResult method call and this clearly indicates that there is a misunderstanding here. I'm hoping to clear the air a bit with this post.

What is the use of Task.FromResult method?

Imagine a situation where you are implementing an interface which has the following signature:

public interface IFileManager
{
     Task<IEnumerable<File>> GetFilesAsync();
}

Notice that the method is Task returning which allows you to make the return expression represent an ongoing operation and also allows the consumer of this method to call this method in an asynchronous manner without blocking (of course, if the underlying layer supports it). However, depending on the case, your operation may not be asynchronous. For example, you may just have the files inside an in memory collection and want to return it from there, or you can perform an I/O operation to retrieve the files list asynchronously from a particular data store for the first time and cache the results there so that you can just return it from the in-memory cache for the upcoming calls. These are just some scenarios where you need to return a successfully completed Task object. Here is how you can achieve that without the help of Task.FromResult method:

public class InMemoryFileManager : IFileManager
{
    IEnumerable<File> files = new List<File>
    {
        //...
    };

    public Task<IEnumerable<File>> GetFilesAsync()
    {
        var tcs = new TaskCompletionSource<IEnumerable<File>>();
        tcs.SetResult(files);

        return tcs.Task;
    }
}

We here used the TaskCompletionSource to produce a successfully completed Task object with the result. Therefore, the caller of the method will immediately have the result. This was what we had been doing till the introduction of .NET 4.5. If you are on .NET 4.5 or above, you can just use the Task.FromResult to perform the same operation:

public class InMemoryFileManager : IFileManager
{
    IEnumerable<File> files = new List<File>
    {
        //...
    };

    public Task<IEnumerable<File>> GetFilesAsync()
    {
        return Task.FromResult<IEnumerable<File>>(files);
    }
}

Should I await Task.FromResult method calls?

TL;DR version of the answer: absolutely not! If you find yourself in need to using Task.FromResult, it's clear that you are not performing any asynchronous operation. Therefore, just return the Task from the Task.FromResult output. Is it dangerous to do this? Not completely but it's illogical and has a performance effect.

Long version of the answer is a bit more in depth. Let's first see what happens when you "await" on a method which matches the pattern:

IEnumerable<File> files = await fileManager.GetFilesAsync();

This code will be read by the compiler as follows (well, in a simplest way):

var $awaiter = fileManager.GetFilesAsync().GetAwaiter();
if(!$awaiter.IsCompleted) 
{
     DO THE AWAIT/RETURN AND RESUME
}

var files = $awaiter.GetResult();

Here, we can see that if the awaited Task already completed, then it skips all the await/resume work and directly gets the result. Besides this fact, if you put "async" keyword on a method, a bunch of code (including the state machine) is generated regardless of the fact that you use await keyword inside the method or not. Keeping all these facts in mind, implementing the IFileManager as below is going to cause nothing but overhead:

public class InMemoryFileManager : IFileManager
{
    IEnumerable<File> files = new List<File>
    {
        //...
    };

    public async Task<IEnumerable<File>> GetFilesAsync()
    {
        return await Task.FromResult<IEnumerable<File>>(files);
    }
}

So, don't ever think about "await"ing on Task.FromResult or I'll hunt you down in your sweet dreams :)

References

Sides and Source Code for DEU Bilgisayar Topluluğu Izmir 2. Teknoloji Zirvesi

This weekend, I participated in an event as a speaker in Izmir, DEU Bilgisayar Topluluğu Izmir 2. Teknoloji Zirvesi. Sides and Source Code for my sessions are available.
2013-01-08 04:34
Tugberk Ugurlu


This weekend, I participated in an event as a speaker in Izmir. I also had the chance to meet Fatih Boy, İkay İlknur, Umut Erkal and Oğuzhan Yılmaz at the event. There were great sessions throughout the first and second day.

A_2F067CMAA2b2FA_2Gty6CIAAOKnf

A_2oQg4CcAERiYOA_2XVl7CUAEjVF9

I gave two talks during the event and one of them was on Git and GitHub. You can see the slides for that session below:

At the second day, I talked about asynchronous programming for .NET server applications. Slides for that session is also available on my SpeakerDeck page. You can also get the source code for the demos: https://github.com/tugberkugurlu/IzmirDEU201301ServerSideAsync.

Why am I not Using NancyFx Instead of ASP.NET MVC / Web API

Why am I not using NancyFx instead of ASP.NET MVC / Web API? Because of a very important and vital missing part with NancyFx: asynchrony!
2012-12-18 19:50
Tugberk Ugurlu


Note: If you don't understand asynchrony and its benefits, you are better off without this blog post. If you are willing to learn the importance of asynchrony for server applications, here are two videos for you to start:

Update 2013-10-08:

Great news! NancyFx now has asyncronous processing ability. See Jonathan Channon's post for more details: Async Route Handling with Nancy 

Server side .NET ecosystem is not just about the frameworks that Microsoft builds and ships such as ASP.NET MVC, ASP.NET Web API, etc. There are other open source frameworks out there such as NancyFx which has been embraced by the community. I haven’t played with NancyFx that much but I really wanted to understand how it is more special than its equivalent frameworks. As far as I can tell, it’s not but I am nowhere near to make that judgment because I only spared 10 minutes to figure that out, which is obviously not enough to judge a framework. Why and where did I stop? Let’s get to that later.

You may have also noticed that I have been kind of opinionated about ASP.NET Web API lately. It’s not because I am writing a book on ASP.NET Web API. The reason of my passion is related to fact that I know how it works internally and I can see that none of the other equivalent frameworks hasn’t been able to get asynchrony right as this framework did (SignalR also gets asynchrony right but it’s kind of a different area)! Please do inform me and make me happy if you think that there is any other framework which we can put under this category. I didn’t put ASP.NET MVC under this category either because it’s not possible to go fully asynchronous throughout the pipeline with ASP.NET MVC. However, it’s has a really nice asynchronous support for most of the cases.

I’m not going to get into the details of how asynchrony is important for a server application because I have tried to do that several times. Let’s stick with the topic: why am I not using NancyFx instead of ASP.NET MVC / Web API? Don’t get me wrong here. NancyFx is a great framework as far as I can see and I’m all supportive for any .NET open source project which makes it easy to get our job done. @TheCodeJunkie and the other NancyFx members have been doing a great job on maintaining this awesome open source framework. However, there is a very important missing part with this framework and it’s vital to any server application: asynchrony! We are now about to see why this is important.

I have created two applications which do the same thing in a different way: downloading the data over HTTP and return it back as a text. I used NancyFx to create one of these applications and this application will make the HTTP call synchronously because there is no way to do it asynchronously with NancyFx. The other application has been implemented using ASP.NET Web API and the only difference will be that it will make the HTTP call asynchronously.

It’s fairly straight forward to get started with NancyFx. I jumped to one of the framework’s documentation page and I was good to go by installing the NuGet package and adding the following module. It was a nice and quick start.

public class HelloModule : NancyModule {

    public HelloModule() {

        Get["/"] = (p) => {

            using (var client = new WebClient()) {
                var textData = client.DownloadString("http://localhost:52907/api/cars");
                return textData;
            }
        };
    }
}

I used WebClient on both applications here because HttpClient has no synchronous methods and making blocking calls with HttpClient has some overheads. I also created an ASP.NET Web API application which does the same thing but asynchronously.

public class DefaultController : ApiController {

    public async Task<string> Get() {

        using (var client = new WebClient()) {

            var textData = await client.DownloadStringTaskAsync(
                "http://localhost:52907/api/cars");

            return textData;
        }
    }
}

As you can see, it’s extremely easy to write asynchronous code with the ".NET 4.5 + C# 5.0 + ASP.NET Web API" combination. You probably noticed that I am making a call against http://localhost:52907/api/cars. This is a simple HTTP API which takes minimum 500 milliseconds to return. This wait is is on purpose to simulate a a-bit-long-running call. Let me also be clear on why I’ve chosen to make a comparison by making an HTTP call. This really doesn’t matter here. Any type of I/O operation could have been a perfect case here but an HTTP call scenario is simple to demonstrate.

Finally, I now have an endpoint on http://localhost:47835 for NancyFx application and another on http://localhost:49167 for ASP.NET Web API application. I have opened up a command line console and get the ab.exe (Apache HTTP Server Benchmarking Tool) under my path. When I generate a request for each one (only one request), I will have a result which is similar to the below screenshot (NancyFx is the lest side, ASP.NET Web API is the right side).

image

Notice that both have taken approx. the same amount of time to complete the request but this’s not the place where asynchrony shines. Let’s now generate totally 200 request (30 concurrent requests at a time) to each endpoint and see the result (NancyFx is the lest side, ASP.NET Web API is the right side).

image

15.31 requests per second with NancyFx + synchronous processing and 49.35 requests per second with ASP.NET Web API + asynchronous processing. Besides the fact that this’s totally an on-the-fly benchmarking (I’m not even sure whether we can call this a benchmark) on my Windows 8 machine, the result is pretty compelling.

Let’s now have a look at the reason why I stopped discovering NancyFx further. Go to NancyFx GitHub repository and navigate to Nancy.Hosting.Aspnet.NancyHttpRequestHandler class file. This is located under the ASP.NET host project for NancyFx and actually the HTTP handler the framework uses to process requests. Earlier today I tweeted after I had a look at this class:

image

Yes, it’s sitting right there. By exposing the framework with a normal handler implementation instead of the IHttpAsyncHandler implementation, you are making your ASP.NET framework suffer. It’s possible for you to handle synchronous calls with an asynchronous handler but it’s impossible (or either not right and easy) to do this with a normal handler. On the other hand, we know that NancyFx doesn’t only have an ASP.NET host option. You can even host this framework under katana with its OWIN Host implementation but it’s not going to matter unless the framework itself has asynchronous processing capabilities and by looking at the above handler and this issue, I can see that it doesn’t have that.

This is not an I-hate-you-and-I-will-stay-that-way-forever-please-go-the-hell-away blog post. Again: NancyFx is a great project and it deserves a good amount of respect. However, this post explains my reason on why I am not using NancyFx instead of ASP.NET Web API or ASP.NET MVC. Will it going to change? Unless #148 is not fixed, it is certainly not. Even if it is fixed, I already have applications running on ASP.NET Web API and ASP.NET MVC. Why bother then? We will see that in the future.

ASP.NET SignalR Alpha 1.0.0 is Now Available!

Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available! Even better! SignalR has just shipped with ASP.NET Fall 2012 Update!
2012-10-31 23:31
Tugberk Ugurlu


Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available.

You can now get the SignalR into your web project through NuGet with the following command:

PM> Install-Package Microsoft.AspNet.SignalR -Pre

Even better! SignalR has just shipped right out of the box with ASP.NET Fall 2012 Update! I tried to have a quick view of what has added and changed. In this post, I will share just a few of them.

When you install the package, you will get the most of the usual stuff.

image

There is one more thing that I haven’t see before (not sure if this has been there with 0.5.3 release). The project is no more registering itself invisibly and RegisterHubs class accomplishes for us.

image

The one other thing that I fell in love with is to be able to return a Task or Task<T> from the hub method! This is a killer feature! Again, I am not sure if this was on 0.5.3 release but I am glad this is now there!

image

And here it is! We have been all waiting for this one Smile We now have an AuthorizeAttribute Smile

image

This attribute implements IAuthorizeHubConnection and IAuthorizeHubMethodInvocation interfaces to be recognized as an authorization attribute. So, this means that you can provide your own! If you are familiar with ASP.NET MVC or ASP.NET Web API, the concept here is the same. However, the interface methods return bool to signal the caller if the call is authorized or not. I would really love to be able to return Task<bool> here or have a similar filter model as ASP.NET Web API. Keep in mind that these are authorization points and they are not meant to be used to perform authantication. SignalR completely leaves the authantication to the underlying hosting layer.

I’m sure there are other features but it is 03:24 AM here and my eyes are closing Smile So, it is enough for now. Big thanks and kudos to @davidfowl and @DamianEdwards for the Alpha release and for bringing this such a great framework to life.

If I were you, I would go to SignalR Github repository and start exploring the samples. They are awesome and cover the new stuff. Also, @DamianEdwards and @davidfowl has a //Build talk tomorrow which will be streamed live: http://channel9.msdn.com/Events/Build/2012/3-034 Don’t miss that one!

More Information

Asynchronous .NET Client Libraries for Your HTTP API and Awareness of async/await's Bad Effects

Writing asynchronous .NET Client libraries for your HTTP API and using asynchronous language features (aka async/await) and some deadlock issue you might face.
2012-09-21 06:34
Tugberk Ugurlu


Haven’t you shot yourself in the foot yet with async/await? If not, you are about to if you are writing a client library for your newly created ASP.NET Web API application with .NET 4.5 using new asynchronous language features.

I wrote a blog post couple of months ago on the importance of Current SynchronizationContext and the new C# 5.0 asynchronous language Features (aka async/await). I wrote that post just after I watched the The zen of async: Best practices for best performance talk of Stephen Toub on //Build 2011 and that was one of the best sessions that I was and still am glad to watch. I learnt so many things from that session and some of them was amazingly important.

Filip Ekberg also has a very nice and useful blog post which has an identical title as my previous post on the topic: Avoid shooting yourself in the foot with Tasks and Async.

The post was pointing out that it is extremely easy to end up with a deadlock if you are not careful enough. The post explains every details but if want to recap shortly, here it is:

When you are awaiting on a method with await keyword, compiler generates bunch of code in behalf of you. One of the purposes of this action is to handle synchronization with the UI thread. The key component of this feature is theSynchronizationContext.Current which gets the synchronization context for the current thread. SynchronizationContext.Current is populated depending on the environment you are in. The GetAwaiter method of Task looks up for SynchronizationContext.Current. If current synchronization context is not null, the continuation that gets passed to that awaiter will get posted back to that synchronization context.

When consuming a method, which uses the new asynchronous language features, in a blocking fashion, you will end up with a deadlock if you have an available SynchronizationContext. When you are consuming such methods in a blocking fashion (waiting on the Task with Wait method or taking the result directly from the Result property of the Task), you will block the main thread at the same time. When eventually the Task completes inside that method in the threadpool, it is going to invoke the continuation to post back to the main thread because SynchronizationContext.Current is available and captured. But there is a problem here: the UI thread is blocked and you have a deadlock!

The post also has a sample but I want dig deep into this. As you all know, ASP.NET Web API RTW version has been shipped couple of weeks ago and we may have started to take advantage of this framework to build our HTTP-based lightweight APIs. You might be using another framework to create your APIs or you might be maintaining an existing one. No matter which category you put yourself in, you are likely to build platform specific client libraries for your API. If you are going to target .NET framework, I am 90% sure that you want your client library to be asynchronous and new HttpClient will just give you that option.

I have started writing a simple blog engine for myself called MvcBloggy nearly a year ago and after the RTW release of the ASP.NET MVC 4 and ASP.NET Web API, I decided to try something different and expose the data through HTTP. So, my ASP.NET MVC application won’t know anything about where my data is store or how I retrieve it. It is just going to consume the HTTP APIs. The application is shaping up nicely and I even started to build my .NET client for the API as well.

Couple of days ago, Ben Foster (a brilliant developer) raised a question on Twitter about consuming asynchronous methods on ASP.NET Web Pages application and I also wondered about that. Then, we looked around a bit and also contacted with Erik Porter (@HumanCompiler), Program Manager on the ASP.NET team, and he confirmed that it is not possible today. He encouraged us to file an issue and we did (#418). This got me thinking about my little project’s .NET client, though. What if I wanted to create a blog web site with ASP.NET Web Pages by consuming the .NET client of my blog engine? I have no option rather than consuming the methods in a blocking fashion but with my current implementation, I am not able to do that because I will end up with deadlocks. Let me prove that to you with a little example which you can also find up on GitHub: AsyncAwaitForLibraryAuthors.

Assuming we have a little API which returns back a list of cars and we want to build a .NET client to consume the HTTP API and abstracts all the lower level HTTP stuff away. The one that I created is as below (it is a simple one for the demo purposes):

public class Car {

    public int Id { get; set; }
    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }
    public float Price { get; set; }
}

public class SampleAPIClient {

    private const string ApiUri = "http://localhost:17257/api/cars";

    public async Task<IEnumerable<Car>> GetCarsAsync() {

        using (HttpClient client = new HttpClient()) {

            var response = await client.GetAsync(ApiUri);

            // Not the best way to handle it but will do the work for demo purposes
            response.EnsureSuccessStatusCode();
            return await response.Content.ReadAsAsync<IEnumerable<Car>>();
        }
    }
}

We leveraged the new asynchronous language features and we were able to write a small amount of code to get the job done. More importantly, we are making the network call and the deserialization asynchronously. As we know from the earlier sentences that if there is a SynchronizationContext available for us, the code that the compiler is generating for us will capture that and post the continuation back to that context to be executed. Keep this part in mind. I put this little class inside a separate project called SampleAPI.Client and reference this from my web clients. I have created two clients: one ASP.NET MVC and one ASP.NET Web Pages applications.

In my ASP.NET MVC 4 application, I have a controller which has two actions. One of these actions will call the API asynchronously and one of will do the same by blocking:

public class HomeController : Controller {

    public async Task<ViewResult> CarsAsync() {

        SampleAPIClient client = new SampleAPIClient();
        var cars = await client.GetCarsAsync();

        return View("Index", model: cars);
    }

    public ViewResult CarsSync() {

        SampleAPIClient client = new SampleAPIClient();
        var cars = client.GetCarsAsync().Result;

        return View("Index", model: cars);
    }
}

Our view is also so simple as follows:

@model IEnumerable<SampleAPI.Client.Car>
@{
    ViewBag.Title = "Home Page";
}

<h3>Cars List</h3>

<ul>
    @foreach (var car in Model) {
        <li>
            @car.Make, @car.Model (@car.Year) - @car.Price.ToString("C")
        </li>    
    }
</ul>

When we navigate to /home/CarsAsync, we will get back the result.

image

However, when we navigate to /home/CarsSync to invoke the CarsSync method, we will see that the page will never come back because we just introduced a deadlock due to the reasons we have explained earlier. Let’s have a look at the Web Pages sample:

@{
    Layout = "~/_SiteLayout.cshtml";
    Page.Title = "Home Page";

    SampleAPI.Client.SampleAPIClient client = new SampleAPI.Client.SampleAPIClient();
    var cars = client.GetCarsAsync().Result;
}

<h3>Cars List</h3>

<ul>
    @foreach (var car in cars) {
        <li>
            @car.Make, @car.Model (@car.Year) - @car.Price.ToString("C")
        </li>    
    }
</ul>

This page is also not going to respond because Web Pages runs under ASP.NET and ASP.NET has a SynchronizationContext available.

When we take a look at our GetCarsAsync method implementation, we will see that it is completely unnecessary for us to get back to current SynchronizationContext because we don’t need anything from the current context. This is good because it is not our (I mean our .NET client’s) concern to do anything under the current SynchronizationContext. It is, on the other hand, our consumer’s responsibility. Stephen Toub said something in his talk on //Build 2011 and the words not the same but it expresses the meaning of the below sentences:

If you are a library developer, the default behavior which await gives you is nearly never what you want. However, if you are a application developer, the default behavior will nearly always what you want.

I, again, encourage you to check that video out.

The solution here is simple. When we are creating our libraries, we just need to be more careful and think about the usage scenarios. In our case here, we need to suppress the default SynchronizationContext behavior that the compiler is generating for us. We can achieve this with ConfigureAwait method of the Task class which was introduced with .NET 4.5. The ConfigureAwait method accepts a Boolean parameter named as continueOnCapturedContext. We can pass false into this method not to marshal the continuation back to the original context captured and our problem would be solved. Here is the new look of our .NET client for our HTTP API.

public class SampleAPIClient {

    private const string ApiUri = "http://localhost:17257/api/cars";

    public async Task<IEnumerable<Car>> GetCarsAsync() {

        using (HttpClient client = new HttpClient()) {

            var response = await client.GetAsync(ApiUri)
                .ConfigureAwait(continueOnCapturedContext: false);

            // Not the best way to handle it but will do the work for demo purposes
            response.EnsureSuccessStatusCode();
            return await response.Content.ReadAsAsync<IEnumerable<Car>>()
                .ConfigureAwait(continueOnCapturedContext: false);
        }
    }
}

When we now run our Web Pages application, we will see the web site working nicely (same is also applicable for the CarsSync action method of our ASP.NET MVC application).

image

If you are going to write a .NET client for your company’s big HTTP API using new asynchronous language features, you might want to consider these facts before moving on. Otherwise, your consumers will have hard time understanding what is really going wrong.

Tags