Implementing an asynchronous settings service, Part 2 : Writing a setting

By jay at October 08, 2012 20:12 Tags: , , , , ,

tl;dr: This article is the second of a series talking about the implementation of an async user Settings Service, using the C# async keyword. This part talks about writing new settings values, asynchronously and the challenges associated with it.

 

In this continuing implementation of a Settings Service series, I'll continue with the addition new features to the service.

Part one talked about reading the settings asynchronously, and this time, we'll talk about writing user settings new values.

 

Writing to the Settings Service

Now let's say that the user has selected a new temperature unit in a weather app, writing a new value to the settings service takes a few more lines, More...

Implementing an asynchronous settings service, Part 1 : Going Async

By jay at October 07, 2012 21:32 Tags: , , , , ,

TL;DR: This article is part of a series about implementing asynchronous services contract, and starts by an the creation of basic functionality for a User Settings storage service using C# 5.0 async features. In the next episode, we'll talk about writing a user setting and consuming settings change notifications.

 

Most applications require the storage of user settings, such as the login, authentication token, preferences, you name it. All these settings have been stored in many locations over the years, such ini files, AppSettings, IsolatedStorageSettings in Silverlight and more recently in RoamingStorage or LocalStorage in WinRT, etc…

Most of the time, this is pretty much CRUD-like contracts that do not offer much to perform asynchronous reading/writing, easy two-way data-binding and notifications. Some offer change notifications, but most of the time, this is related to roaming settings that have been updated.

Reading settings in a synchronous way is a common performance issue, and most of the time accessing the data can be expensive, which is not good for the user experience. For instance, the Silverlight and Windows Phone IsolatedStorageSettings implementation has a pretty big performance hit during the first access, due to the internal use of Xml Serialization (and its heavy use of reflection). It also requires to be synchronized during persistence, and its persistence takes a lot of time too, suspending simultaneous read or write operations.

In this article, I’m going to discuss an implementation of a service that abstracts the use of application or users settings using the C# async/await keywords.

More...

C# Async Tips and Tricks, Part 3: Tasks and the Synchronization Context

By jay at September 29, 2012 21:12 Tags: , , , , , , , ,

TL;DR: It is possible to mix C# async and basic TPL style programming, but when doing so, the synchronization context capture feature of C# async is not forwarded to TPL continuations automatically, making UI dependent (and others) code fail and raise exceptions. This can lead to the termination of the process when exceptions are not handled properly, particularly in WinRT/C# apps.

 

I’ve discussed in a previous article of this series, the relation between async Task/Void methods and the ambient SynchronizationContext.

Just as a simple reminder, when executing a async method, whether it is Task, Task<T> or Void returning, the caller’s SynchronizationContext is captured to ensure that all the code in an async method is executed in the same context. The main scenario for this is to easily execute UI bound code in an async method.

It is important to remember that async methods are based on the TPL framework, and that async methods (except in infamous async void) return System.Threading.Tasks.Task instances.

More...

An update to @matthieumezil, Rx and the FileSystemWatcher

By jay at August 26, 2012 20:52 Tags: , , , , , , ,

@MatthieuMEZIL is a fellow MVP and friend of mine, and back in february at the MVP summit we shared our mutual interests with Rx on my side, and Roslyn on his side.

I’ve yet to blog about Roslyn, (even though a blog post is in preparation) but he started using Rx and is a bit blogging about it.

Now, Rx is a tricky beast and there are many ways to do the same thing. I’ve promised Matthieu I’d give him a few tricks on how to improve his code. Now that I do have a bit of time, here it is.

More...

C# Async Tips and Tricks Part 2 : Async Void

By jay at July 08, 2012 17:05 Tags: , , , , , , ,

TL;DR: This article discusses the differences between async Task and async void, and how async void methods and async void lambdas, used outside the DispatcherSynchronizationContext, can crash the process if exceptions are not handled.

You can also read the part 3, Tasks and the Synchronization Context.

In the first part of the series, we discussed the behavior of async methods. The second part discusses how async Task and async void methods can differ in behavior, while seemingly being similar.

 

Authoring Async Methods

Async methods can be authored in three different ways:

async Task MyMethod() { }

which creates a method that can be awaited, but does not return any value,

async Task<T> MyReturningMethod { return default(T); }

which creates a method that can be awaited, and returns a value of the type T,

async void MyFireAndForgetMethod() { }

which is allows for fire and forget methods, and cannot be awaited.

You may be wondering why there are two ways to declare a void returning method. Read on.

More...

C# 5.0 Async Tips and Tricks, Part 1

By jay at June 18, 2012 21:22 Tags: , , ,

Cet article est aussi disponible en francais.

TL;DR: This article is a discussion about how C#5.0 async captures the executing context when running an async method, which allows to easily stay on the UI Thread to access UI elements, but can be problematic when running CPU-bound work. Off of the UI thread, an async method may jump from thread to thread, breaking thread context dependent code along with it.

You can also read : Part 2, Async void 

C# 5.0 has introduced, language-wise, just two of new features (async and caller information) and a gotcha fix (a lambda lifted foreach loop variable scope change).

The biggest addition though, in terms of compiler magic, is the addition async. It’s been covered all over the place, and I will just comment the addition feature by itself, and the impacts it has when using it.

This article is the first of a small series about some C# async tricks and gotchas that I will try to cover to give a bit of insight, and hopefully help developers avoid them.

More...

[WPDev] The hidden cost of IL Jitting

By jay at December 02, 2011 22:35 Tags: , , , , , , ,

We’ve gotten used to it. Method jitting is negligible. Or is it really ?

 

IL JITing

The compilation from IL to the native architecture assembly language (or JITting) has been part of the CLR from the very beginning. That’s an operation that was added to make the code execute faster, as interpreting the IL was too slow. By default, it’s happening on the fly, when the code path comes to a method that needs to be jitted, and that impacts the code speed when executing the method the first time.

That compilation step is not exactly free. A lot of code analysis and CPU specific optimizations are performed during this step. This is what arguably makes already JITted code run faster than generic compiled code, where the compiler has no knowledge of the target architecture.

This analysis takes a bit of time, but it is taking less and less time to execute, due to CPUs getting faster, or multi-core JITting features like the one found in .NET 4.5.

We’ve come to a point, on desktop and server machines, where the JIT time is negligible, since it’s gotten fast enough not to be noticed, or be an issue, in the most common scenarios.

Still, if there were times when JITing would be an issue, like it used to be around .NET 1.0, NGEN would come to the rescue. This tool (available in a standard .NET installation) pre-compiles the assemblies for the current platform, and creates native images stored on the disk. When an assembly is NGENed, they appear in the debugger’s “module” window named as “your_assembly.il.dll”, along with some other fancy decorations.

But while there are some caveats, like the restrictions with cross assembly method inline being ignored. It always comes down to a balance between start-up speed and code execution speed.

 

JITing on Windows Phone

On the phone though, CPU is very limited, especially on Generation 1 (Nodo) phones. The platform is too, considering is relative young age. At least on surface.

We’ve got used to create quite a bit of code to ease the development, add levels of abstraction for many common concepts, and lately, for asynchrony.

I’ll take the example of Reactive Extensions (Rx) in this article, just to make a point.

If you execute the following code on a Samsung Focus:

    
    List<timespan> watch = new List<timespan>();

    var objectObservable = Observable.Empty<object>();

    var w = Stopwatch.StartNew();
    Observable.Timeout<object>(objectObservable, TimeSpan.FromSeconds(1));
    watch.Add(w.Elapsed);

    w = Stopwatch.StartNew();
    Observable.Timeout<object>(objectObservable, TimeSpan.FromSeconds(1));
    watch.Add(w.Elapsed);

    output.Text = string.Join(", ", watch.Select(t => t.TotalMilliseconds.ToString()));

You'll consistently get something similar to this :

    20.60, 1.19


Calling an Rx method like this does almost nothing, it’s basicallt just setup. But 20ms is a long time ! Particularly when done on the UI thread, or any other thread for that matter.

These rough measurements tend to show that the Windows Phone platform (as of Mango at least) is not performing any NGEN like pre-jitting, leaving the app the burden of jitting code on the fly.

Still, not everything can be accounted to JITing, there must be type metadata loading, type constructors that are called.

 

Generating code with T4

So to sort that out a bit more, let’s use some T4 templates to generate code and isolate the JIT a bit more :

<#@ template language="C#" #>
using System;
using System.Collections.Generic;

public class Dummy
{
   public static void Test()
   {
      List<int> list = new List<int>();

      <#for (int i = 0; i < 100; i++) { #>
	  list.Add(<#= i.ToString() #>);
      <#} #>
   }
}

 

For different values of iterations, here's what gets out, when timing the call to the method :

Calls First call Subsequent calls
100 1.6ms > 0.03ms
1000 15.7ms > 0.09ms
5000 72.8ms > 2 ms
10000 148ms > 2ms

 

While this type of code is not exactly a good real-life scenario, this shows a bit the cost the IL jitting step. These are very simple method calls, no branching instructions, no virtual calls, … in short, nothing complex.

But with real code, the IL is a bit more intricate, and there’s got to be more logic involved in the JIT when generating the native code.

 

Wrapping up

Unfortunately, there’s not much that can be done here, except by reducing the amount of actual lines of IL that are generated. But that can be a though job, particularly when customers are expecting a lot from applications.

One could suggest to push as much code as  possible on a background thread, even code that seemingly does nothing particularly expensive. But that cannot always be performed on an other thread, particularly if that code depends on UI elements.

Finally, pre-jitting assemblies when installing the applications could be an interesting optimization for the Windows Phone platform, and I’m wondering why this has not made its way to the platform yet…

WinRT and the syntactic sugar around .NET event handlers

By jay at October 17, 2011 19:48 Tags: , , , , ,

If you've watched the great number of videos available from the Build conference, you've probably noticed that the layer between .NET and WinRT is very thin.

So thin that in permeates through to C# 5.0, even though it's not immediately visible to the naked eye.

 

Also, that Windows 8 developer preview is pretty stable... I'm writing this blog post using it, and it's pretty good :) (lovin' the inline spell checker, everywhere !!)

 

What about WinRT ?

The Windows Runtime has been explained here, there and by Miguel de Icasa (and there too by Julien Dollon), but to summarize in other words, WinRT is (at least for now) the new way to communicate with the Windows Core, with an improved developer experience. It's the new preferred (and only, as far as I know) way to develop Metro style applications, in many languages like C#/F#/VB, C++, JavaScript and more...

The API is oriented toward developing tablet applications, with the power and connectivity limitation that kind of platform has, plus the addition of what makes Windows Phone so interesting. That means Live Tiles, background agents, background transfers, XAML, background audio, social APIs, camera, sensors, location, and new features like sharing and search contracts, ...

My favorite part of all this is the new addition of a rule that make a LOT of sense : If an API call nominally takes more than 50ms to execute, then it's an asynchronous api call. But not using the ugly Begin/End pattern, rather through the nice async/await pattern, WinRT style (I'll elaborate on that in a later post). I've even started to apply that rule to my existing development with the Reactive Extensions (And that's yet an other later post).

Microsoft has taken the approach of cleaning up the .NET framework with the ".NET Core" profile. For instance, the new TypeInfo class now separates the introspection part from the type safety part that were historically merged in the System.Type type. This segregation limits the loading of type metadata only when necessary, and not when just doing a simple typeof(). Now, the System.Type type is fairly simple, and to get back all the known methods like GetMethods() or GetProperties() there's an extension method called Type.GetTypeInfo() in System.Reflection that gives back all the reflection side.

There are a lot of other differences, I'll discuss in a later post. (yeah, that's a lot to talk about !)

For the .NET developer, WinRT takes the form of *.winmd files that follow the .NET standard metadata format (kind of like TLB files on steroids, if you know what I mean...). These files can be directly referenced from .NET code like any other assembly, it's then very easy to call the underlying Windows platform. No more P/Invoke.

Just before you start freaking out, WinRT does not replace the standard .NET 4.5 full platform you already know, remember that. That's just a new profile, much like Windows Phone or Xbox 360 are profiles, but targeted at Metro style applications. (It's not applications anymore, it's apps :) just so you know...)

 

But how thin is the layer, really ?

To accommodate all these languages, compromises had to be made and underneath, WinRT is native code. Native code means no garbage collection, limited value types, a pretty different exception handling (SEH), and so on.

The CLR and C# compiler teams have made a great job at trying to hide all this but there are still some corner cases where you can see those differences appear.

For instance, you'll find that there are two EventHandler types : the existing System.EventHandler, and the new Windows.UI.Xaml.EventHandler. What's the difference ? See for yourself :

namespace System
{
    [ComVisible(true)]
    public delegate void EventHandler(object sender, EventArgs e);
}

And the other one :

namespace Windows.UI.Xaml
{
    // Summary:
    //     Represents a basic event handler method.
    [Version(100794368)]
    [WebHostHidden]
    [Guid(3817893849, 19739, 19144, 164, 60, 195, 185, 8, 116, 39, 152)]
    public delegate void EventHandler(object sender, object e);
}

The difference is subtle, but it's there : the second parameter is an object. This is kind of troubling, and having to juggle between the two is going to be a bit messy. That's going to be the forced return of conditional compilation and the myriads of #if and #endif...

But the difference does not stop here though. Let's look at how the WinRT handler can be used :

public class MyCommand : Windows.UI.Xaml.Input.ICommand
{
    public event Windows.UI.Xaml.EventHandler CanExecuteChanged;

    public bool CanExecute(object parameter) { }

    public void Execute(object parameter) { }
}

Translates to this, after the compiler does its magic :

using System.Runtime.InteropServices.WindowsRuntime;
public class MyCommand : Windows.UI.Xaml.Input.ICommand
{
    public event Windows.UI.Xaml.EventHandler CanExecuteChanged
    {
        add
        {
            return this.CanExecuteChanged.AddEventHandler(value);
        }
        remove
        {
            this.CanExecuteChanged.RemoveEventHandler(value);
        }
    }

    public bool CanExecute(object parameter) { }

    public void Execute(object parameter) { }

    public MyCommand()
    {
        this.CanExecuteChanged = 
           new EventRegistrationTokenTable();
    }
}

The delegates are not stored in a multicast delegate instance like they used to be, but are now stored in an EventRegistrationTokenTable type instance, and provides a return value for the add handler ! Also, the remove handler "value" is a EventRegistrationToken instance.

That construct is so new that even the intellisense engine is mistaken by this new syntax if you try to write it by yourself, but it compiles correctly.

The return value is of type EventRegistrationToken, and I'm guessing that it must be something WinRT must keep track of to call marshaled managed delegates.

The calling part is also very interesting, if you try to register to that event :

// Before
MyCommand t = new MyCommand();
t.CanExecuteChanged += (s, e) => { };
// After
MyCommand t = new MyCommand();
WindowsRuntimeMarshal.AddEventHandler(
   new Func(t.add_CanExecuteChanged)
 , new Action(t.remove_CanExecuteChanged)
 , delegate(object s, object e) { }
);

Quite different, isn't it ?

But this syntactic sugar seems only to be related to the fact that the WinRT EventHandler delegate type is exposed as a implemented interface member, like in ICommand. It does not appear if it is used somewhere else.

 

Cool. Why should care ?

Actually, you may not care at all, unless you write ICommand implementations.

If you write a command, and particularly ICommand wrappers or proxies, you may want to write your own add/remove handlers and to be able to do so, you'll need to return that EventRegistrationToken too, and map that token to your delegate.

Here's what I came up with :

public class MyCommand : Windows.UI.Xaml.Input.ICommand
{
    EventRegistrationTokenTable _table = new EventRegistrationTokenTable();
    Dictionary _reverseTable = new Dictionary();
        
    public event EventHandler CanExecuteChanged
    {
        add
        {
            var token = _table.AddEventHandler(value);
            _reverseTable[token] = value;

            // do something with value

            return token;
        }

        remove
        {
            // Unregister value 
            RemoveMyHandler(_reverseTable[value]);

            _table.RemoveEventHandler(value);
        }
    }
}

All this because the EventRegistrationTokenTable does not expose a bi-directional mapping between event handlers and their tokens.

But remember, WinRT and Dev11 are in Developer Preview state. That's not even beta. This will probably change !

To be fair when comparing Rx to C# 5.0 Async...

By Admin at August 03, 2011 20:45 Tags: , , , , ,

After reading the 900th morning brew, one article by mike taulty about comparing Rx, TPL and async caught my attention.

Mike tries to explain the history, differences and similarities between all these frameworks, and kudos, that's not an easy thing to do.

Asynchrony, (and I'm not talking parallelism), is a complex topic that fools even the best of us.

 

Comparing Rx and Async

Rx and Async and much more similar in that regard, because going off to an other thread is not mandatory, and most operators use either the CurrentThread (timebase priority queue) scheduler or the Immediate (passive wait) scheduler.

This means that the code you are writing is doing some cooperative multi-threading, or fibers-like processing. Everything happens on the same thread, except that work is optionally being queued up, and that thread works as long as there's work left to do, then waits for outstanding operations. These oustanding operations can be I/O completion port bound, like Stream.BeginRead/EndRead.

But back to the comparison, mike is trying to do buffer reading of content from a web response stream, and doing so using the Async CTP's ReadAsync and WriteAsync eases a lot the writing of that kind of code. (Also, the Rx example does not work correctly, but I'll talk about that later in this post.)

These two functions are not tied to the complexity of the BeginRead/EndRead, and behave very much like an IObservable would. Call ReadAsync, you get a Task and wait on it.

Let's jump to the end result and we can get this with Rx based composed operators, using methods symilar to the ReadAsync and GetResponseAsync :

string url = "http://www.microsoft.com";

var webRequest = WebRequest.Create(url);

webRequest.ToResponse()
          .SelectMany(wr => wr.GetResponseStream().ToBytes())
          .ForEach(
            b => Console.WriteLine(Encoding.Default.GetString(b))
          );

That way, it is a lot easier to read. ToResponse maps to GetResponseAsync and ToBytes maps to ReadAsync.

I'll concede the complexity of the SelectMany operator that is related to the fact that IObservable deals with sequences (the duality with IEnumerable). What we would need is more like a IObservableValue that returns only one value. At that point, an appropriate operator would be something like SelectOne, but that's an other topic I'll discuss soon.

 

The ToResponse operator

This one is easy, and is pretty much an encapsulation of the code provided in Mike's Rx example :

public static IObservable ToResponse(this WebRequest request)
{
    var asyncGetResponse = Observable.FromAsyncPattern(
                            request.BeginGetResponse, request.EndGetResponse);

    return Observable.Defer(asyncGetResponse);
}

The use of defer allows the execution of the actual call to GetResponse when someone is subscribing to the deffered observable.

 

The ToBytes operator

That one is a bit tricker :

public static IObservable ToBytes(this Stream stream)
{
    return 
        Observable.Create(
            observer =>
            {
                byte[] buffer = new byte[24];

                var obsReadFactory = Observable.Defer(() => stream.AsReader()(buffer, 0, buffer.Length));

                return Observable
                         .Repeat(obsReadFactory)
                         .Select(i => buffer.Take(i).ToArray())

                         // Subscribe on the thread pool, otherwise the repeat operator will operate during the 
                         // call to subscribe, preventing the whole expression to complete properly
                         .SubscribeOn(Scheduler.ThreadPool)

                         .Subscribe(
                             _ =>
                             {
                                 if (_.Length > 0)
                                 {
                                     observer.OnNext(_);
                                 }
                                 else
                                 {
                                     observer.OnCompleted();
                                 }
                             },
                             observer.OnError,
                             observer.OnCompleted
                         );
            }
        );
}

and needs a bit of explaining.

The ToBytes extension is creating a Observable that will be able to control finely the OnNext/OnCompleted events, especially because of the loopy nature of the BeginRead API. Loopy means that in a synchronous mode, you needs to call Read through a loop until you get all you need. The BeginRead/EndRead still expose this loopy nature, but in an asynchronous way.

With Rx, that loop can be introduced with the use of Repeat, the same way a while(true) would do.

The Select operator is pretty straightforward, even if it may not be as fast as a Buffer.BlockCopy, it's pretty conscise.

The SubscribeOn is the tricky part of this method, and is very important for the OnCompleted events to get through. If this operator is not present, the call to the ToBytes method blocks in the Subscribe of the SelectMany operator in the final example. This means that events like OnCompleted get buffered and not interpreted, and the repeat operator will continue indefinitely to turns into loops getting nothing, because noone's unsubscribing. This would be CPU consuming, and memory consuming because the observable expression could not get dispose.

Then in the subscribe, we notify the observer that either there's a new buffer, or that we're done because the EndRead method returned 0 (or an exception).

 

Continuing the comparison

All this to say that the .NET 5.0 (or whatever it will be called) has a Task friendly BCL that makes it easy to write asynchronous code.

I'm definitely not saying that Rx is as easy as Async will be, but, with a minimum of understanding and abstraction, it can be as powerful and even more powerful because of its ability to compose observables.

Now, for the issues in Mike's Rx sample :

  • The TakeWhile operator only completes when the source observable completes, and the source is a Repeat observable, which never ends, meaning that the whole subscription will never get disposed
  • The Observable.Repeat operator runs on the Immediate scheduler, meaning that the OnNext method will be called in the thread context of the original Subscribe, and the expression will not get disposed.

The sample actually shows something, but the CPU will stay at 100% until the process ends.

 

A word on Asynchrony

Asynchrony is a complex topic, very easy to get wrong, even with the best intentions. Parallelism is even more complex (and don't get me started on the lock() keyword).

I'm expecting that People are going to have a hard time grasping it, and I'm worried that Async will make it too easy to make parallelism (not asynchrony this time) mistakes, because it is will be easy to introduce mutating states in the loop, hence hard to reproduce transitory states bugs. Calling "new Thread()" was scary, and for good reasons, but using await will not, but with mostly the same bad consequences.

I'd rather have better support for immutable structures method or class purity and some more functional concepts baked into C#, where the language makes it harder to make mistakes, than trying to bend (or abstract) asynchrony to make it work with the current state of C#.

Then again, I'm not saying Rx is better, it's trying to work around the fact that the BCL and C# 3.0 don't have asynchrony baked in, so the complexity argument still stands.

 

On the other side, the more developers use Async, the more developers will need async savvy consultants as firemen :)

 

 

About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.