Question

Let’s put aside for the moment, the question of whether synchronous-like operations should even be attempted within the context of a Silverlight app. If I use ManualResetEvent as in the following code:

    static string result;
    static AutoResetEvent are = new AutoResetEvent(false);
    static ManualResetEvent mre = new ManualResetEvent(false);
    public static string AsyncCall()
    {
        string url = "https://stackoverflow.com/feeds/tag/silverlight";
        WebClient w = new WebClient();
        w.DownloadStringCompleted += new DownloadStringCompletedEventHandler(w_DownloadStringCompleted);
        w.DownloadStringAsync(new Uri(url), url);
        mre.WaitOne();
        return result;
    }

    static void w_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
    {
        result = e.Result;
        mre.Set();
    }

As you’d expect from reading ManualResetEvent on MSDN, “When the controlling thread completes the activity, it calls the Set method to signal that the waiting threads can proceed.”, when Set() is called in w_DownloadStringCompleted, control returns to the waiting thread that started waiting in AsyncCall. This is what happens when running this with .NET 4.0. The thread in AsyncCall gets blocked until the download completes and Set is called.

If I run the same piece of code in Silverlight 4, DownloadStringAsync will get called, yet control will never reach the w_DownloadStringCompleted callback. Once WaitOne() is called, that thread in AsyncCall just hangs there, and the thread which took off to process DownloadStringAsync never reaches the callback. The only way I’ve seen a thread reach the download callback in SL4 is if the thread from AsyncCall returns from AsyncCall. So Set() never gets called.

Why doesn’t ManualResetEvent work as expected in Silverlight 4? Why does it differ from .NET 4?
Is this maybe Microsoft’s enforcement of the asynchronous design pattern?
Or is there something I’m missing?

Thanks

Answer 1

The networking callbacks in Silverlight will always arrive in the same thread as they were originated. For example, if you make a WebClient.DownloadStringAsync on the UI thread (i.e., on a button click event), then the callback call will be queued to be delivered on the same UI thread. However, your call to mre.WaitOne() is blocking the UI thread, so the callback is never invoked, and the mre.Set() call never happens.

So yes, that’s a kind of enforcement in the asynchronicity of networking calls – you really can’t do synchronous calls, even if they seem to be synchronous.