CORRECTION:  The threading model in Silverlight has changed as of Silverlight 2 Beta 2.  It is now possible to initiate asynchronous communication from any thread,  however,  asynchronous callbacks now run in “new” threads that come from a thread pool.  The issues in this article still apply,  with two additions:  (1) the possibility of race conditions and deadlocks between asynchronous callback threads and (2) all updates to user interface components must be done from the user interface thread.  (Fortunately,  it’s easy to get back to the UI thread.)  Subscribe to our RSS Feed to keep informed of breaking developments in Silverlight development.

There’s a lot of confusion about how asynchronous communication works in RIA’s such as Silverlight, GWT and Javascript. When I start talking about the problems of concurrency control, many people tell me that there aren’t any concurrency problems since everything runs in a single thread. [1]

It’s important to understand the basics of what is going on when you’re writing asynchronous code, so I’ve put together a simple example to show how execution works in RIA’s and how race conditions are possible. This example applies to Javascript, Silverlight, GWT and Flex, as well as a number of other environments based on Javascript. This example doesn’t represent best practices, but rather what can happen when you’re not using a proactive strategy that eliminates concurrency problems:

In the diagram above, execution starts when the user pushes a button (a). This starts the user interface thread by invoking an onClick handler. The user interface thread starts two XmlHttpRequests, (b) and (c). The event handler eventually returns, so execution stops in the user interface thread.

In the meantime, the browser still has two XmlHttpRequests running. Callbacks from http requests, timers and user interfaces go into a queue — they get executed right away if the user interface thread is doing nothing, but get delayed if the user interface thread is active.

Http request (b) completes first, causing the http callback for request (b) to start. Had something been a little different with the web browser, web server or network, request (c) could have returned first, causing the callback for request (c) to start. If the result of the program depends on the order that the callbacks for (b) and (c) run, we have a race condition. The callback for http request (b) starts a new http request (d), which runs for a long time.

In the meantime, the user is moving the mouse and triggers a mouseover event while the request (b) callback is running. Right after the request (b) callback completes, the web browser starts the UI thread, which causes a mouseover event handler (e) to run. Note that the user can trigger user interface events while XmlHttpRequests are running, causing event handlers to run in an unpredictable order: if this causes your program to malfunction, your program has a bug.

While the event handler (e) is running, request (c) completes: like the mouseover event, this event is queued and runs once event handler (e) completes. Before (e) completes, it starts a new http request (f). The browser looks into the event queue when (e) completes, and starts the callback for (c). Http request (f) completes while callback (c) is running, gets queued, and runs after (c) is running.

At the end of this example, the callback for (f) completes, causing the UI thread to stop. The http request (c) is still in flight — it completes in the future, somewhere off the end of the page.

This example did not include any timers, or any mechanism of deferred execution such as DeferredCommand in GWT or Dispatcher.Invoke() in Silverlight. This is but another mechanism to add callback references to the event queue.

As you can see, there’s a lot of room for mischief: http requests can return in an arbitrary order and users can initiate events at arbitrary times. The order that things happen in can depend on the browser, it’s settings, on the behavior of the server, and everything in between. Some users might use the application in a way that avoids certain problems (they’ll think it’s wonderful) and others might consistently or occasionally trigger an event that causes catastrophe. These kind of bugs can be highly difficult to reproduce and repair.

Asynchronous RIAs have problems with race conditions that are similar to threaded applications, but not exactly the same. Today’s languages and platforms have excellent and well documented mechanisms for dealing with threads, but today’s RIAs do not have mature mechanisms for dealing with concurrency. Over time we’ll see libraries and frameworks that help, but asynchronous safety isn’t something that can be applied like deodorant: it involves non local interactions between distant parts of the program. The simplest applications can dodge the bullet, but applications beyond a certain level of complexity require an understanding of asynchronous execution and the consistent use of patterns that avoid trouble.

[1] Although it is possible to create new threads in Silverlight, all communication and user interface access must be done from the user interface thread — many Silverlight applications are single-threaded, and adding multiple threads complicates the issue.

Oliver Steele writes an excellent blog about coding style,  and has written some good articles on asynchronous communications with a focus on Javascript.

Minimizing Code Paths In Asynchronous Code,  a recent post of his,  is about a lesson that I learned the hard way with GWT that applies to all RIA systems that use asynchronous calls.  His example is the same case I encountered,  where a function might return a value from a cache or might query the server to get the value:   an obvious way to do this in psuedocode is:

function getData(...arguments...,callback) {
   if (... data in cache...) {
      callback(...cached data...);
   }
  cacheCallback=anonymousFunction(...return value...) {
     ... store value in cache...
     callback(...cached data...);
  }

   getDataFromServer(...arguments...,cacheCallback)

}

At first glance this code looks innocuous,  but there’s a major difference between what happens in the cached and uncached case.  In the cached case,  the callback() function gets called before getData() returns — in the uncached case,  the opposite happens.  What happens in this function has a global impact on the execution of the program,  opening up two code paths that complicate concurrency control and introduce bugs that can be frustrating to debug.

This function can be made more reliable if it schedules callback() to run after the thread it is running in completes.  In Javascript,  this can be done with setTimeout().   In Silverlight use System.Windows.Threading.Dispatcher.  to schedule the callback to run in the UI thread.

Asynchronous Commands are a useful way to organize asynchronous activities, but they don’t have any way to pass values or control back to a caller. This post contains a simple Asynchronous Function library that lets you do that. In C# you call an Asynchronous Function like:

 void CallingMethod(...) {
    ... do some things ...
    IAsyncFunction<String> httpGet=new HttpGet(... parameters...);
    anAsynchronousFunction.Execute(CallbackMethod);
}

void CallbackMethod(CallbackReturnValue<String> crv) {
    if (crv.Error!=null) { ... handle Error,  which is an Exception ...}
    String returnValue=crv.Value;
    ... do something with the return value ...
}

We’re using generics so that return values can be passed back in a type safe manner. The type of the return value of the asynchronous function is specified in the type parameter of IAsyncFunction and CallbackReturnValue.

Asynchronous functions catch exceptions and pass them back in  in the CallbackReturnValue.  This makes it possible to propagate exceptions back to the caller,  as in synchronous functions.  The code to do this must has to be manually replicated in each asynchronous function,  however,  the code can be put into a wrapper delegate.

You could do the same thing in Java, but the CallbackMethod would need to be a class that implements an interface rather than a delegate.

Continue Reading »

When you’re writing RIA applications in an environment like Silverlight or GWT, you’re restricted to doing asynchronous http calls to the server — this leaves you with a number of tricky choices, such as, where to put your callback functions. To be specific, imagine we’ve created a panel in the user interface where a user enters information, then clicks on a form to submit it. The first place you might think of putting the callback is in the class for the panel, something like

public class MyPanel:StackPanel {
	... other functions ...

        void SubmitButton_Click(Object sender,EventArgs e) {
           ... collect data from forms ...
           ServerWrapper.DoSubmission(formData,SubmissionCallback);
        }

        void SubmissionCallback(SubmissionResult result) {
           ... update user interface ...

        }

}

(Although code samples are in C#, the language I’m using now, I developed this pattern when working on a Java project.) This is a straightforward pattern for the simplest applications, but it runs out of steam when your application becomes more complex. It can become confusing to keep track of your callback functions when your object does more than one kind of asynchronous call: for instance, if it has multiple buttons. If the same action can be done on the server from more than one place in the UI, it’s not clear where the callback belongs.

One answer to the problem is to use the Command Pattern, to organize asynchronous activities into their own classes that contain both the code that initiates an asynchronous request and the callback that runs when the request completes. Continue Reading »

I’m in the middle of updating my Silverlight code to use asynchronous HTTP requests — fortunately, I spent last summer writing a GWT application, where HTTP requests have always been asynchronous, so I’ve got a library of patterns for solving common problems.

For instance, suppose that you’re doing a search, and then you’re displaying the result of the search. The most reliable way to do this is to use Pattern Zero, which is, do a single request to the server that retrieves all the information — in that case you don’t need to worry about what happens if, out of 20 HTTP requests, one fails.

Sometimes you can’t redesign the client-server protocol, or you’d like to take advantage of caching, in which case you might do something like this (in psuedo code):

getAListOfResults(new AsyncCallback {
     ... clearGUI();
         foreach(result as item) {
            fetchItem(item,new AsyncCallback {
               ... addItemToGui()
         }
}

First we retrieve a list of items, then we retrieve information about each item: this is straightforward, but not always reliable. Even if your application runs in a single thread, as it would in GWT or if you did everything in the UI thread in Silverlight, you can still have race conditions: for instance, results can come back in a random order, and getAListOfResults() can be called more than once by multiple callbacks — that’s really the worst of the problems, because it can cause results to appear more than once in the GUI.

There are a number of solutions to this problem, and a number of non-solutions. A simple solution is to make sure that getAListOfResults() never gets called until the result set has come back. I was able to do that for quite a while last summer, but the application finally reached a level of complexity where it was impossible… or would have required a major redesign of the app. Another is to use pessimistic locking: to not let getAListOfResults() run while result sets are coming back — I think this can be made to work, but if you’re not careful, your app can display stale data or permanently lock up.

Fortunately there’s a pattern to retrieve result sets using optimistic locking that displays fresh data and can’t fail catastrophically

Continue Reading »

I developed a rather complicated GWT application last summer and spent plenty of time struggling with the concurrency issues involved with with applications that use asynchronous web requests: for instance, the HttpWebRequest in Silverlight or the XmlHttpRequest in Javascript. Up until Silverlight 2 beta, Silverlight programmers could perform synchronous requests, but the latest version of Silverlight supports only asynchronous requests… We’re scrambling to update our apps.

There’s a “standard model” that works for writing reliable, performant and secure RIAs — it works for GWT, Flex, and Silverlight and plain old AJAX apps too.

Continue Reading »