Silverlight Hack

Silverlight & related .NET technologies

About Me

Welcome to  This is a site where you can find many articles on Silverlight, Windows Phone 7 and .NET related technologies.  

My name is Bart Czernicki.  I have been working with computers since 1988 and have over 12 professional years in the IT field focusing on architecture, technology strategy and product management.  I currently work as a Sr. Software Architect at a large software development company.

Below is the cover of my new book that shows how Silverlight's unique RIA features can be applied to create next-generation business intelligence (BI 2.0) applications.

Silverlight 4 Business Intelligence Soft 


View Bart Czernickis profile on LinkedIn

NONE of the comments or opinions expressed here should be considered ofmy past or current employer(s).  The code provided is as-is without anyguarantees or warranties.

Windows Phone 7 Development Tip: Use Concurrent Programming Techniques

Windows Phone 7 devices are out in the wild; now we can finally test if those emulator performance enhancements truly work.  There is A LOT of misinformation out there about the hardware of the Windows Phone 7 devices.  You can see that the Windows Phone 7 hardware utilizes the 1st generation SnapDragonprocessor which includes a single CPU.  However, the single physical CPU is able to effectively manage multiple threads concurrently.

Today I had a chance to deploy a Windows Phone 7 sample from my book to a physical Windows Phone 7 device and I was pleasantly surprised that the multithreading performance in the emulator is reflected on the physical phone device.  The sample I wrote was a simple slider that is tied to a fake activity of 150ms of CPU "work".  On the physical device the second slider (shown below) completely locks up the entire device and the application becomes unusable.  The third slider is very responsive, because it uses a secondary thread to manage the work.


I included the source code here.  If you are interested in how this optimization works, refer to Chapter 10 (Concurrent Programming) and Chapter 12 (Mobile Intelligence) of my book.  I have blogged numerous times about concurrent programming in Silverlight herehere and here.  Even in my current book, I devoted an entire chapter to concurrent programming in Silverlight 4 including an example for the Windows Phone 7.  Since Windows Phone 7 apps run Silverlight 3 (plus a little Silverlight 4 with some threading changes) all these multithreading techniques I have written about (in my book and online) will apply.

Posted: Nov 09 2010, 18:33 by Bart Czernicki | Comments (0) RSS comment feed |
  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Social Bookmarks: E-mail | Kick it! | DZone it! |

Silverlight 3 and F# Support in Visual Studio 2010

The goal of this blog post is to make you aware of F# support in Silverlight in Visual Studio 2010.  In addition, this blog post shows an example why F# is going to be very important for Silverlight architects and developers.  Note:  This is NOT an intro to F#.

Demo and Visual Studio 2010 source code are provided with this article.

In Visual Studio 2010, F# is a first-class language.  Over the last several months, the language has been "productized."  It is officially part of the Visual Studio 2010 ecosystem (tools and .NET 4.0 framework).  However, F# is not limited to the full .NET framework; it is also available in the Silverlight runtime.  This is really exciting as this allows you to take advantage of functional programming features in Silverlight.


In Visual Studio 2010, the "F# Silverlight Library" project is natively supported.


Silverlight 3 application that includes an F# assembly.


Why should I care about F# in Silverlight?

Most C# developers/architects who do not have experience with functional programming language features could assume that F# is another language like Visual Basic, J# or C++.  It would be wrong to compare F# to any of these languages (including C#).  As a functional language, F# allows developers to design software using the functional paradigm.  What does that mean?  This means functional patterns such as interactive programming, pattern matching, immutable data types, type inference, lambda expressions, workflows, higher-order functions, discriminated unions, etc., are all included in F#.  While taking advantage of these features, a developer using F# can use the type system, implement object-oriented design and make use of the .NET classes.  This makes F# a very unique language that combines all the features of a first-class .NET language (i.e., C#) and a professional functional language.

Note: F# compiles to IL just like any other .NET language.  However, F# has been designed from the ground up over the last couple of years.  Therefore, the IL it generates has been optimized and many new language optimization features have been implemented.  For example, you may have seen blog posts that compare C# and F# syntax that shows F# compiling into cleaner IL and faster code.  Conversely, C#'s core functionality has not been redesigned in about a decade (C#/.NET has been extended with functional features such as type inference, extension methods, lambdas, AST, LINQ, etc.)


Show me some code that proves how F# can add value to Silverlight

This short blog post is not meant to be an F# introduction (Please see links below for intro material).  However, I did want to pick at least one compelling feature that really shows off the power and functional brevity of F# married with Silverlight functionality.  The feature that I decided to show off in a Silverlight F# module is a concurrent programming pattern.

If you do not already know, Silverlight supports distributing logic up to eight processor cores (This frustrates me that Microsoft doesn't adverstise this enough). In my opinion, concurrent programming is THE biggest feature of Silverlight over other RIA technologies (i.e., Flash, JavaFX).  However, implementing asynchronous patterns in Silverlight is not trivial.  The callback pattern is messy and leads to a lot of code.  Silverlight runs in an STA mode and requires UI elements to only be modified by the main thread (dispatching or synchronization).  Even asynchronous constructs like the BackgroundWorker that are supposed to make concurrent programming simple lead to many messy lines of code with events.  Wouldn't it be great to get the benefit of asynchronous programming without having to write many lines of additional code?

One of the fantastic features of F# is that the default type immutability and functional design allows the language to express the desired result declaratively.  This means you write F# syntax by telling the program what you want it to do rather than how to do it.  For example, if you are using constructs that use secondary threads and allocate code to these threads, then you are writing imperative code.  A lot of lines of code are wasted telling the code how we want it to behave.  Wouldn't it be better to define pieces of logic and simply say that we want them to execute in parallel?  Functional declarative code in F# can do exactly that.  F# includes a feature called asynchronous workflows that allow you to write logic by composition with the aim to be executed in parallel.

Initial Steps

  • I created a simple Silverlight application.
  • I added an "F# Silverlight Library" project
  • In the F# assembly, I added an F# code file called ConcurrencyTest.fs.
  • I created an F# function called addNumbers that takes two parameter:
    • The first parameter is an accumulator that is the existing sum in the running sequence (This will be passed by the reduce sequence function).
    • The second parameter is the number in the sequence we want to add.
  • I created an F# function called squareNumber that takes two parameters:
    • The first parameter is an accumulator that is the existing square sum in the running sequence (This will be passed by the reduce sequence function).
    • The second parameter is the number in the sequence we want to square.
  • I created an F# function (equivelant to a C# method) that takes no input parameters named PerformTwoLongRunningTasks:
    • Inside that function, I defined two tasks that use the addNumbers and squareNumber functions to add the numbers across a sequence of numbers from 0 to 10,000,000
    • The PerformTwoLongRunningTasks function returns an array of 64-bit integers.  The array of 64-bit integers are the results of the two aggregates functions.
    • The first function returns the sum of the numbers.  The second function returns the square of the numbers.

The F# static method/function is shown below (Some familiarity with F# is required to understand what is going on, but I commented on the code for those unfamiliar with F#):

Now that we have this function (static method) defined in our F# library, it is ready to be used.  In the Silverlight application, we can add a reference to the F# library and then we can call the function (static method) as shown below in our C# Silverlight MainPage class.  Note that below we are calling the function just like we would call a static method with the [Name of Class].[Name of public function].  Notice also that because F# uses the base .NET type system, the returned array of integers does not need special casting/marshalling to C#.

Parallizing the Tasks

Now it is time to parallize the two tasks and scale it across multiple logical/physical processor cores.  As mentioned earlier, we are going to accomplish this with asynchronous workflows. In the figure below, I highlighted the changes to the function and it now scales across multiple cores.  This was done in two steps:

  • Wrap the body of the member functions with the async {... } syntax.
    • Add a return keyword (This signifies the return parameter/completion of the body).
    • The body of the function Seq.reduce addNumbers {0L..10000000L} now becomes async { return Seq.reduce addNumbers {0L..10000000L} }.
  • The main function (PerformTwoLongRunningTasks) now returns an array of async tasks.  These can be thought of delegates that need an Invoke-type command to execute them.  We simply change let results = [| task1; task2 |] to let results = Async.RunSynchronously (Async.Parallel [ task1; task2 ]).
    • All this does is tells the F# compiler to parallize these tasks.  However, run the result synchronously.  Therefore, the code returns to the main thread and we do not need dispatching/synchornization, etc.  This is analogous to creating a wait event in C# and having the two pieces of logic scheduled on secondary threads and waiting for this process to come back.

Asynchronous workflows allowed us to simply wrap the tasks as an "async function" declaratively.  This is a very important distinction as we just declared the logic and told it we want this to run in parallel.  Notice we didn't tell it "how to run in parallel" (imperative code).  Therefore, we did not have to:

  • explicitly start, stop threads (i.e., Thread.Start)
  • use BackgroundWorker
  • use callbacks (AsyncCallBack)
  • use BeginExecute asynchronous pattern

We simply told the code we want the tasks distributed among multiple cores and let the F# compiler figure out the hard part and generate the IL.  This is really powerful and in the very near future of "declarative parallel processing".  This is an example of what I mentioned earlier that the F# compiler has been designed recently and can include this type of "magic" right in the language.  C# does not have this feature and needs to be extended to provide this kind of automation.

Can't I do this with PLINQ?

Those familiar with the Parallel Extensions Libraries that will be added to .NET 4.0 might be aware that LINQ has been extended with parallelism features.  This allows you to extend your existing LINQ queries with parallism features.  This is known as PLINQ (parallel LINQ).  For example, a screen shot below shows a LINQ query that can be easily parallized by simply adding the AsParallel() extension method.

Unfortunately, the Parallel Extensions Library will NOT be available for Silverlight for the Visual Studio 2010 release.  However, I think that there is a good chance future versions of Silverlight will eventually get this feature.  There are some big features in the Silverlight assemblies that are simply missing and need to be added before features like PLINQ can be added.  This is exactly where asynchronous workflows can be substituted for PLINQ in a Silverlight application.  If you are working with large data sets, complex math computations, AI for a game, etc., parallelizing your code in F# libraries makes pefect sense for a Silverlight application.  This is MUCH easier than writing your own imperative multithreaded code.

How about the Performance?

I extended the functions and created functions for two, four and eight tasks and put this in a Silverlight application.  On my workstation (four cores), there was about a 50% improvement by parallelizing the two tasks.  With four tasks, the improvement in performance was about 3.5x.  As you can see, asynchronous workflows can easily dramatically improve the performance of your code on the Silverlight client.

Click the picture below to launch the demo application


Getting started with F#

Information on F# has been around for several years.  There are many articles, white papers, and books on F#.  However, you do have to be careful and get content that is recent and relative to the current F# release.  The F# specification has changed dramatically over the last several months as the language was being "productized" and many methods/functions simply don't exist in F# anymore.   Below are some links I put together where to get started.


  • Getting Started with F# - This video (from the 2008 PDC) is the place to start if you have zero F# experience and/or if you want a really good introduction into functional programming and some F# examples.

Books (I have read four different F# books and the two below are by far the best ones and most current.  Don Syme's F# book is good but a little outdated.)


  • This the main Microsoft F# page.  Includes numerours links, downloads for Visual Studio, F# extensions, etc.
  • Don Syme's blog - Don Syme is one of the main "creators" of F#.  His blog is a must read to get insight into advanced topics and upcoming F# news.


I hope this post gets Silverlight architects/developers exited about upcoming F# support.  F# is another tool that software architects can use that helps them create better software.  Furthermore, F# suport is another example of Microsoft's ability to integrate the Silverlight runtime across the .NET development stack.

kick it on
Posted: Nov 04 2009, 16:16 by Bart Czernicki | Comments (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Social Bookmarks: E-mail | Kick it! | DZone it! |

Silverlight MultiThreading with a Computational Process (Counting Primes)


In my previous post about multithreading I looked at the importance of using multithreaded techniques to improve the performance of the UI controls. This post focuses on using multiple threads to improve computational performance inside Silverlight.

I saw this article by Tim Anderson comparing Silverlight and Flash in a computational situation by counting primes.  I also saw derivatives of this article comparing the performance of Silverlight vs JavaScript/TraceMonkey.  Silverlight is a clear winner in both articles.  However, we can do better.  This article will focus on how we can improve the performance of Tim's code by adding multithreaded processing inside Silverlight.  I am not focusing on math theory, the counting prime algorithm or hacks to make other versions better.  This article focuses on some straightforward Silverlight 2 multithreading optimizations.

kick it on

Demo and Beta 2 Source Code are provided.

Update 10/14/2008..The demo is now on Silverlight 2 RTM and the Silverlight 2 Source Code is up.

Overview of the example & demo:

First, check out Tim Anderson's example and run the example on your machine to see what we are going to be optimizing.  Also, note the performance of the runtime on your workstation.  Run it a couple of times each to get a good baseline. Silverlight should be faster by a factor of 4.



So let's improve the code with more threads (remember, not the algorithm; I want to keep it the same).  I created a small application that has the standard implementation (standard code); an example with two threads and an example with three threads.  Click on the example below to launch it.


  • The first button is essentially Tom's code and performs the code in single thread
  • The second button spins up 2 threads using the BackgroundWorker to calculate the primes (using the same code in the first button)
  • The third button spins up 3 threads using the BackgroundWorker to calculate the primes  (using the same code in the first button)
  • The last input UI control is a textbox that allows you to enter an integer (1 to whatever) to add a factor of 1,000,000 to end with.  For example, 2 will calculate the primes for 2,000,000 integers;  3 will calculate for 3,000,000 integers.  This way we can increase the number of integers we want to calculate by simply changing the integer in the text box  (There is a specific reason why I implemented the prime counter to use this method as I cheat a little bit in the implementation.  More on that below)
Overview of the multithreaded implementation: 

My implementation of how the multiple threads calculate a single process (i.e., counting the primes from 1 -> 1,000,000) is very similar to the logic that is implemented by the Microsoft Parallel Extensions.  Check out the video on Channel 9 where Joe Duffy and Igor Ostrofsky explain how some of the parallel extensions work.  I would recommend watching the entire video; however, you can ffwd to about the 8 minute mark to get a decent understanding of the logic I am mimicking.  Below is a screen shot of the logic that the parallel LINQ uses when dealing with some kind of process on a data structure like an array:

Let's overview the logic that Parallel LINQ uses (It does MUCH more than this, but we are doing something simple at a high level):

  • We have an input array of 5 numbers.
  • In the logic above we are spinning up 2 threads.
    • The first thread will do some kind of processing on the integers: 3, 1, 2
    • The second thread will do some kind of processing on the integers: 5, 6
  • Each thread will store each product in an intermediate data structure
  • After both threads are completed, then the output from the two intermediate structures is combined and returned to the main thread.

This is exactly the same logic I am using for counting primes in a multithreaded environment.

  • We have a number of integers we want to count primes to (i.e., 1,000,000)
  • Say we want to use three threads to calculate primes from 1 -> 1,000,000
    • The first thread will handle the numbers between 1 -> 333,332
    • The second thread will handle the numbers between 333,333 -> 666,666
    • The third thread will handle the numbers between 666,667 -> 1,000,000
  • As each thread finishes, it adds to the count of the integers that are primes.
  • When all three threads finish, the final result is reported back to the main UI thread.
Overview of the key lines of code:

In my previous writeup, I used the BackgroundWorker to implement the processing on multiple threads for this demo.  In this example, I do everything manually and you could write logic to dynamically spin up the necessary threads as needed using delegates.  Like I mentioned, this code mimicks the high level logic in the parallel extensions library.  In the future, I hope that they release a parallel extensions dll for Silverlight which will do exactly what we are simulating in this example/demo.

The code below handles the calculating of primes for three threads:

  private void CalculatePrimesOptimizedThreeThreads_Click(object sender, RoutedEventArgs e)  {  // Reset the variables.  this.threadsReportingThree = 0;  this.multiThreadedPrimesThree = 0;  this.multiThreadedStartThree = DateTime.Now;  /*  You do not want to do this in production code.  I would do something like this once the delegates support async thread invocation.  Func callCalcAsync = this.calculateNumberOfPrimes;  callCalcAsync.BeginInvoke(1, 500000, [add callback method], null);  */  this.bw31.RunWorkerAsync();  this.bw32.RunWorkerAsync();  this.bw33.RunWorkerAsync();  }  

The code in the event handler above simply resets the timespan & count variables. Finally, it spins up the three seperate threads in order to process 1/3rd of the counting of the 1,000,000 primes.

  void bw31_DoWork(object sender, DoWorkEventArgs e)  {  e.Result = this.calculateNumberOfPrimes(1, 333332*this.multiplyFactor);  }  void bw32_DoWork(object sender, DoWorkEventArgs e)  {  e.Result = this.calculateNumberOfPrimes(333332 * this.multiplyFactor + 1, 666666 * this.multiplyFactor);  }  void bw33_DoWork(object sender, DoWorkEventArgs e)  {  e.Result = this.calculateNumberOfPrimes(666666 * this.multiplyFactor + 1, 1000000 * this.multiplyFactor);  }  

The code above shows the processing of each of the three threads do after they are initiated by the RunWorkerAsync() method (in the first code snippet).  Each of the threads calls the calculateNumberOfPrimes method with the respective procesing range passed in.  Simple stuff.

  void bw3_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)  {  // Poor way to do a waithandle. Don't do this in production code.  // Use the waithandle...that's what it's there for.  I am keeping this simple.   // until Silverlight 2 gets full async support  object lockObject = new object();  lock (lockObject)  {  this.threadsReportingThree++;  this.multiThreadedPrimesThree += (int)e.Result;  // Don't do anything until both threads have reported.  if (this.threadsReportingThree == 3)  {  DateTime end = DateTime.Now;  Double timetaken = end.Ticks - this.multiThreadedStartThree.Ticks;  timetaken = timetaken / 10000000;  this.lblCalculatePrimesOptimizedThreeThreads.Text = "Number of primes up to: " + 1000000 * this.multiplyFactor + " is " + this.multiThreadedPrimesThree.ToString() + ", counted in " + timetaken + " secs.";  }  }  }  

In the code above, we are performing the last step of our parallel extensions simulation.  We are synchornizing the result of the three background threads.  As each thread finishes, we add to the number of primes that each thread process has found.  When all three threads finish, we report the result the the UI (main thread).  Note, we do perform a lock on the processing code as we could appear in a race condition with two threads finishing at the same time.  The probability of this is small; however, not thinking about these things usually results in intermittent code and causes weird bugs to occur.  Furthermore,  the more threads to sync, the higher the probability of errors like this occuring.

Performance Gain Tests

Before we start looking at the demo numbers, we need to understand that this processing doesn't come free.  Spinning up extra threads from the threadpool, figuring out which section of work each thread should process, storing the results in intermediate structures and finally synchronizing the threads all have an associated processing cost with them.  Obviously, in production you could adjust the multithreaded logic based on your data/environment(s), make it configurable or make it dynamic and figure out which is the best way to process.  Longer running processes done on client machines with multiple cores will benefit from this multithreaded implementation than those that don't meet this criteria.

Performance Gain Tests - Test Core 2 Due 2.2 GigHz

The first test machine is a Core 2 Duo 2.2 GigHz.  The workstation has two physical cores, so it can handle multiple processes better than a single core processor.  Depending on your workstation specs, you may receive different results.  This is a typical standard desktop/laptop you could buy from Dell/HP in the last 1.5-2 years. 

Test 1 (counting the number of primes from 1 -> 1,000,000).  Factor is the default: 1

  • Single thread time: .362 seconds
  • Two threads time:  .256 seconds
  • Three threads time: .257 seconds

Notice right off that multithreading the computation already netted a nice performance gain of over 40%!  Notice there isn't much of a difference between two threads and three threads.  Remember, when I mentioned above that there is a cost associated with each thread you use in splitting up processing on each core.  Obviously, the cost here is roughly equal to the benefit.  Therefore, they wash each other out and three threads process in about the same total time as two threads.  One way to mitigate the cost of multiple threads on a core is to increase the amount of available cores :)

Test 2 (counting the number of primes from 1 -> 5,000,000).  Factor is the default: 5 (dramatically increases the processing time).  I ran these tests multiple times and picked the lowest run I received (You will receive different results as you may have different items running in the background on your workstation).

  • Single thread time: 3.194 seconds
  • Two threads time:  2.031 seconds
  • Three threads time: 1.719 seconds

In this example, we can see that the difference between the single threaded and dual threaded implementation is about 1.1 seconds!  That is a huge difference.  Let's look at the three thread implementation.  It actually came in 0.3 seconds lower than the two thread implementation.  So now we are seeing some benefits of our third implementation.  It is not very drastic; however, as we increase the processing needed, the difference gap will increase further in the time span.  The percentage different should remain roughly the same.

Performance Gain Tests - Dual Processor Quad-Core HaperTown 5420 (Intel Xeon 2.5 GigHz)

The second test machine is a server: Quad-Core 2.5 GigHz.  The server has 8 physical cores.  This test is just to show what results we come up with when the cores are increased by 4x. 

Test 1 (counting the number of primes from 1 -> 1,000,000).  Factor is the default: 1

  • Single thread time: .234 seconds
  • Two threads time:  .15625 seconds
  • Three threads time: .1093 seconds

With a higher class of processor, these times are a lot faster than the previous results.  However, with 2 extra cores now our three thread implementation is already 42% faster than the two thread implementation.  Note that during our test on a dual core, the three thread implementaton was indentical to the two thread implementation.

Test 2 (counting the number of primes from 1 -> 5,000,000).  Factor is the default: 5 (dramatically increases the processing time).  I ran these tests multiple times and picked the lowest run I received (You will receive different results as you may have different items running in the background on your workstation).

  • Single thread time: 2.25 seconds
  • Two threads time:  1.401 seconds
  • Three threads time: 0.997 seconds

The times are obviously faster and the margins are about equal between the last test (The three thread implementation is about 40%+ faster than two thread implementation). The performance of the three threads is 125% faster than a single threaded computation!

What's happening during the tests?

If you have a dual-core or a quad-core workstation, you can try this yourself by simply opening up task manager (while testing different implementations).  I set the factor to 15 to count the number of primes from 1 -> 15,000,000.  This will simulate a longer running process that hopefully registers properly on the task manager.

Above is a screen shot of the task manager CPU usage of both cores while performing the prime calculation for 15,000,000 integers.  The data in the red box was captured for the single threaded implementation.  The data in the blue box was captured for the multithreaded implementation (2 threads).  Notice from the graph that the duration for the single threaded implementation is longer than the multithreaded implementation.  Furthermore, during that duration the single threaded implementation does not take full advantage of both cores.  The CPU does some switching automatically for the process; however, it's not perfect.  Contrast this with the multithreaded implementation which spikes both cores to 100% and keeps it at 100% until the processing has finished.  The graph in the blue is the kind of graph you want to see from a fully multithreaded process.

Who cares?  Why would I want to do this in a web app?

In the world of Web 1.0 and maybe even Web 2.0 days, you probably would want to leave heavy processing to a server or move to a fat client application.  With the start of cloud computing, Web 3.0 or "Web OSes" more is expected from web sites inside the browser.  Multithreading isn't just about AJAX and calling a web service anymore.  Inside Silverlight, you can do some real powerful optimizations by leveraging multiple threads.  This can be useful in a lot of areas.  Just to name a few:

  • Silverlight game programming (i.e., AI)
  • Applications that handle a lot of data
  • Simple math/physics simulations
  • Server monitoring of processes, databases, etc.

If you are professional programmer reading this, I hope I don't have to convince you to utilize multithreaded patterns in your code to net 40% performance gains! :) Just take a look at the net gain on a server machine with three threads...125%!  This is with my simple/manual/hacky waithandle logic, so there is definitely more improvement to be netted here.

My last two articles gave detailed examples of multithreading, which were an intro to my next post in my Silverlight Master Series. 

Beta 2 Source code: (544.08 kb)

Silverlight 2 RTM code: (543.73 kb)

Posted: Sep 07 2008, 13:23 by Bart Czernicki | Comments (4) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Social Bookmarks: E-mail | Kick it! | DZone it! |

Sliverlight Multithreading with Controls (Slider example)

In the next couple of entries in my Silverlight Series, I am going to talk about multithreading, LINQ, etc., and how they can be used inside Silverlight to create rich applications.  However, I thought it might be a good idea to give a simple and well-explained example of before delving too much into why multithreading in Silverlight is important (vice versa). In this article, I want to briefly introduce multithreading inside Silverlight and the show how one can improve UI performance by introducing secondary threads into the events from UI controls.

Demo and Source Code are provided.

Update 10/14/2008..The demo is now on Silverlight 2 RTM and the Silverlight 2 Source Code is up.


Silverlight runs as a plug-in inside the browser.  Some people describe it as "Flash" or a virtual desktop.  The virtual desktop is a good analogy to desktop (fat client) programming.  Those familiar with writing desktop applications know if you have long-running method calls (i.e., scanning the hard drive), making a database call or a web service call, that is done on the main UI thread by default.  Experienced developers know that making these calls on the main thread can cause the UI to become unresponsive or completely give the appearance of a blank UI window.  Creating a responsive UI usually entailed the desktop developer delving into mulithreading the background calls and keeping the main thread primarily to be used for UI operations.  Silverlight UI development shares these UI characteristics of desktop development.

The Silverlight team at Microsoft wants Silverlight to shine and perform "out of the box" by making the multithreaded choice for you. 

  • If you have done any kind of Silverlight service call, you already have a mental note that Silverlight already does a lot work for you on secondary threads.  Calling a WCF service or an ADO.NET Data Service is done on a secondary thread with all the events properly dispatching to the main thread.  This is a plus that developers not too familiar with .NET & multithreading can create responsive (in terms of UI) applications because they have no other choice :)
  • Silverlight takes this further and certain objects like the StoryBoard or Timers are also done on seperate threads.  This allows the developer/designer to create animations without having to worry about multithreading for performance as it is done for you. 
  • When you first hit a website that has Silverlight content, it will be brought down while a progress inidicator (whether it is the default or a custom implementation) shows how far along a user is in downloading content.  While the last example is not a true example of multithreading inside Silverlight, it does amplify the fact that Silverlight has a lot of multithreaded content "out of the box" and nudges the UI developer towards that way.

Not everything inside Silverlight multthreading is "out of the box" and a professional Silverlight developer has to understand that adding expensive calls based on UI controlled events will cause the Silverlight application to beome unresponsive.  Luckily Silverlight 2 includes a rich subset of the .NET 3.5 (SP1) stack and there are many options for developers dealing with multithreaded design.

Example & Demo with the Slider control

The Slider is a real basic control inside Silverlight.  You have seen the Slider implementated anywhere as a volume control or even as a query tool (i.e., Amazon diamond search).  A slider is designed to have a smooth user experience.  The user should be able to quickly move the slider thumb into position and clearly know what value they are on.

What if the movement of the slider thumb is associated with an expensive calculation, web service call or long LINQ query?  The demonstration below shows us three different sliders:

  • The first slider is a simple slider that performs a very quick output to the UI with how many times the move event was fired and the current value of the slider thumb.
    • Notice how many events are fired for just a simple "slide movement".
    • Just a simple movement from beginning to end can cause event handler to be called 30+ times (This depends on how slow you move the slider).
  • The second slider simulates a heavy operation.  It includes a 150ms operation inside the event handler method.
    • Notice the "sliding" movement operation is now seriously degraded.
    • The granularity of the slider is also impaired.  Because of the delay, it is harder to move the slider to the exact position we want.
    • Fast slider movement causes "big jumps" in the slider.
  • The third slider includes the EXACT same 150ms delay simulation.  The big difference is that the "heavy work" is done on a seperate thread and not on the main thread.
    • Notice the performance compared to the second slider.
    • The granularity and thumb movement is a lot better.  The user would not even notice that there is a significant process being done behind the scenes.
Code Overview

The source code is commented and self-explanatory for the most part. I do want to go over the multithreaded implementation in Silverlight.  Silverlight 2 Beta 2 currently does not support asynchronous delegates.  There are a few ways to write multithreaded processes.  The best way in Beta is probably utilizing the BackgroundWorker class.  Those familiar with desktop programming will be familiar with the implementation.  The BackgroundWorker automatically controls the secondary thread and properly threads dispatching through events/delegates.  It makes adding expensive processes on secondary threads trivial.

Let's go over some key parts of the code:

We declare the BackgroundWorker as a field, so it is properly scoped and can be used throughout the code file.  Furthermore, we want to wire up two events to their methods.  RunWorkerCompleted event fires after the work on the secondary thread has completed.  We can use this to get a result from the work or simply notify the UI that the process has finished.  The DoWork is the actual process that will be executed on the secondary thread.  This method will simulate the heavy work.

// declare background workerBackgroundWorker bw = new BackgroundWorker();public Page(){InitializeComponent();// wire up background worker += new RunWorkerCompletedEventHandler(bw_RunWorkerCompleted); += new DoWorkEventHandler(bw_DoWork);}

Now that we have the our BackGroundWorker defined and wired up to fire methods, we need to declare these two methods: 

  • The bw_DoWork method is pretty simple and just puts the current thread to sleep for 150 milliseconds.  Note that when you are in this thread, you are executing on the background thread not the main thread.  So this will put the secondary thread to sleep, not the main UI thread.  Furthermore, you cannot access any UI objects.  This will throw a cross-reference exception.
  • The bw_RunWorkerCompleted method is called after the 150 millisecond delay is complete.  This method is called on the main UI thread so it is safe to access UI objects.  What happens in this method is simple; Since I am done processing whatever my slider move caused, I simply notify the UI what the current value is.
    • Note the code calls itself again if the user moved the slider while the code was in the middle of processing on the second thread.
void bw_DoWork(object sender, DoWorkEventArgs e){// add a fake delay of 150 milliseconds (3/20 of a second)System.Threading.Thread.Sleep(150);}void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e){// Set the slider value to its text box// Notice this is set here, as it guarantees that the value is now officially set// Setting it in the SliderMultiThreaded_ValueChanged event, the 2nd thread would have to catch up to the UIthis.txtSliderMultiThreadedValue.Text = this.SliderMultiThreaded.Value.ToString();// Run the background worker again in case the Slider value needs to catch up// If you stop the slider at the end, for example, it might be still processing the previous event// You want to make sure that where the slider is stopped (last event fired) matches what was processed by the 2nd threadif (!{// If the values are not in sync, then the 2nd thread needs to catch up to the UIif ((this.SliderMultiThreaded.Value != this.LastMultiThreadedSliderValue) && (this.LastMultiThreadedSliderValue != 0.0)){// Run the process again, if the last value set has not been run by the second;// set the value to 0.0this.LastMultiThreadedSliderValue = 0.0;}}}

Kicking off the asynchronous process is simply done by calling the RunAsync() method on the BackgroundWorker variable (bw in our example) in the SliderMultiThreaded_ValueChanged event. This method is non-blocking on the UI thread and if you debug it, it will look like it finishes instantly. It actually spins up a secondary thread and performs the logic inside the bw_DoWork() method we defined above.  Notice below that the code only fires the asynchronous process if the BackGroundWorker is not busy.  This is key, as this will throw an exception if we try to kick off another process on the BackGroundWorker if it is not done.  This is why we have to do the "catch up" step above because the secondary thread could be busy processing the work while the user triggers another slider change event by moving the slider thumb.

private void SliderMultiThreaded_ValueChanged(object sender, RoutedPropertyChangedEventArgs e){// increment multi threaded slider event countthis.countSliderMultiThreaded++;// Set the last value set compared to the current valuethis.LastMultiThreadedSliderValue = this.SliderMultiThreaded.Value;// Execute the work on a second threadif (!bw.IsBusy){bw.RunWorkerAsync();}// Set the count on the text boxthis.txtSliderMultiThreadNumberEventFires.Text = this.countSliderMultiThreaded.ToString();}
Compare to other RIA  Technologies (Flex, Java)

How does this compare to Flash/Flex?  As of now even with Silverlight's limited multithreading support (Dispatcher, StoryBoards, BackgroundWorker, Services/Sockets, etc.), it actually is a lot better than Flash/Flex.  Flash/Flex DO NOT have multithreading support (at least as I understand it).  There is some multithreading in Flash 10 (which is also in beta).  I do not use Flash/Flex, from what I understand the new multithreading capabilites are more behind the scenes and do not include a first class multithreading and thread synchronization environment.  I was pretty suprised when I found that out and I see that is a huge problem for Flash/Flex. 

Many people who disagreed with me in my previous post when I listed the advantages of Silverlight over Flash at least agreed .NET favored Silverlight.  .NET is too much of a broad statement to simply state a simple advantage because of the MANY subpoints that .NET brings to Silverlight.  Simply saying .NET as an advantage is a big understatement. First class multithreading support is a huge win for Silverlight vs Flex/Flash.  Why does this matter?  Because any computer made in the last couple of years probably has a dual processor or more inside it.  It is all about adding cores not adding processing speed.  Silverlight takes advantage of this and it's only in beta!  You could write a similar slider application inside Flash/Flex with some tricks (using a resource govenor to manage the thread like context switching), but why would you want to??!!  Silverlight is already way ahead in the multithreading game compared to Adobe's RIA product.

JavaFX does have multithreading support for certain keywords used as triggers.  I wouldn't call it the same thing that Silverlight 2 RTM will offer.  However, JavaFX and Java can be used together and Java does offer full multithreading support.  Silverlight is nice in that it offers first class support all in one spot in one language.

Conclusion & Future

With this demo, I tried to drive home the point that in order to create the best UI experience for Silverlight users, ensure that you leverage all of the features inside the .NET Framework.  In my opinion, this is what makes Silverlight shine compared to other RIA technologies.  Silverlight 2.0 Beta 2 includes several options to add multithreading capabilities to your RIA applications.  Once delegates are added and are able to invoke methods asynchronously, this logic can become a lot more clearer and lot more functional looking (.NET 3.5 -> lambda expressions, etc.). 

In the RTM release I see Silverlight supporting full delegates with dynamic invoking and my hope is that PLINQ/Parallel Library will come to Silverlight as well.  If those two things happen, Silverlight will be the clear leader for multithreaded RIAs and allow you to write very performant applications.

kick it on

Silverlight 2 Beta 2 Code: (545.41 kb)

Silverlight 2 RTM Code: (547.45 kb)

Posted: Sep 01 2008, 12:06 by Bart Czernicki | Comments (11) RSS comment feed |
  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Social Bookmarks: E-mail | Kick it! | DZone it! |