Long time readers will recall that I’ve done some oddball parallel articles over the years. I recently decided to challenge myself with porting the Task Parallel Library to Silverlight 4. The port is complete and all unit tests pass. I’m still profiling but I’m generally encouraged by the results.
A fair question. Why do I need libraries for making it easier to write multithreaded code in Silverlight?
First, Silverlight is making big strides as a platform for Business applications. Business applications might be able to absorb extra computing power on the client machine. I envision data analysis applications doing lots of work on the client PC. Silverlight Games might be another case when you are doing a lot of game-world updating or computations yourself. What about popular distributed computing applications like Folding @Home or SETI?
Then, of course, there’s the fact that we find ourselves doing minor threading work on Silverlight applications already today. For example, at work I have a Silverlight application which imports data from very large Excel files on background threads. The fact is that the Task model, the Cancellation Token model, and the Concurrent Data Structures are just really nice programming models.
Comments on the TPL Port, and Porting in General
I didn’t start from scratch. The Mono Project has been working on an implementation for their .NET 4 stack. Most of the credit, then, goes to Jérémie "Garuma" Laval. I grabbed all of System, System.Collections.Concurrent, System.Collections.Concurrent.Partitioners, System.Threading, and System.Threading.Tasks and brought things in one class at a time as I needed them to get System.Threading.Tasks to compile.
Some comments on the port:
- Serializable – A good example of something that’s missing from Silverlight. I find that I tend not to comment these things out but rather make an attribute that does nothing. If Silverlight supports this in the future or I discover something useful I could do the mock version is nice.
- No Thread.Yield in Silverlight – I was worried things like this being missing would kill this port. After doing some research, replacing these with Thread.Sleep(0) should have the desired effect.
- No Interlocked.Read in Silverlight – I’m most worried by this omission. Interlocked.Read allows you to do atomic operations on long integers in a 32bit process, which Silverlight always is until Silverlight 5. I don’t have pointers or any other workarounds that I could think of either. This means in the work-stealing portions of the Queues that parallel tasks use I have some operations that need to be atomic but aren’t. I may go back and change these to 32bit integers. No one wants to wait on a long integer’s worth of Tasks anyway.
- No Thread priority in SIlverlight- The task parallel library portions that dealt with thread priority had to be #-defined out.
- Array.Convert() – Missing from Silverlight, but easy to re-create as an extension method.
Performance and Source Code
I am doing some profiling to see if there’s anything I can do to increase performance. Running the same unit tests on this port and the full .NET framework has revealed that this code isn’t as fast on Silverlight. Still, as I said I think having this programming model is pretty nice even without perfectly linear per-core speedups.
I will release the source code if there’s interest. I believe the Mono license allows me to do this as long as I leave their license in tact in the the source files. I should definitely head out to user voice and ask for some of these features in a future version of Silverlight.