The slides and code from my talk on the new async language features in C# and VB.Net are now available on https://github.com/ReedCopsey/Effective-Async
Typically, I strongly recommend keeping the user interface within an application’s main thread, and using multiple threads to move the actual “work” into background threads. However, there are rare times when creating a separate, dedicated thread for a Window can be beneficial. This is even acknowledged in the MSDN samples, such as the Multiple Windows, Multiple Threads* sample. However, doing this correctly is difficult. Even the referenced MSDN sample has major flaws, and will fail horribly in certain scenarios. To ease this, I wrote a small class that alleviates some of the difficulties involved.
Version 4.0 of the .NET Framework included a new CLR which is almost entirely backwards compatible with the 2.0 version of the CLR. However, by default, mixed-mode assemblies targeting .NET 3.5sp1 and earlier will fail to load in a .NET 4 application. Fixing this requires setting useLegacyV2RuntimeActivationPolicy in your app.Config for the application. While there are many good reasons for this decision, there are times when this is extremely frustrating, especially when writing a library. As such, there are (rare) times when it would be beneficial to set this in code, at runtime, as well as verify that it’s running correctly prior to receiving a FileLoadException.
C# and .NET, overall, really do have fantastic performance in my opinion. That being said, the performance characteristics dramatically differ from native programming, and take some relearning if you’re used to doing performance optimization in most other languages, especially C, C++, and similar. However, there are times when revisiting tricks learned in native code play a critical role in performance optimization in C#.
I recently ran across a nasty scenario that illustrated to me how dangerous following any fixed rules for optimization can be…
The Visual Studio team today released an update to the Visual Studio Async CTP which allows it to be used with Visual Studio SP1. This new CTP includes some very nice new additions over the previous CTP. The main highlights of this release include:
- Compatibility with Visual Studio SP1
- APIs for Windows Phone 7
- Compatibility with non-English installations
- Compatibility with Visual Studio Express Edition
- More efficient Async methods due to a change in the API
- Numerous bug fixes
- New EULA which allows distribution in production environments
Anybody using the Async CTP should consider upgrading to the new version immediately. For details, visit the Visual Studio Asynchronous Programming page on MSDN.
In a recent thread on the MSDN forum for the TPL, Stephen Toub suggested mixing ConcurrentDictionary<T,U> with Lazy<T>. This provides a fantastic model for creating a thread safe dictionary of values where the construction of the value type is expensive. This is an incredibly useful pattern for many operations, such as value caches.
While the Visual Studio Async CTP provides a fantastic model for asynchronous programming, it requires code to be implemented in terms of Task and Task<T>. The CTP adds support for Task-based asynchrony to the .NET Framework methods, and promises to have these implemented directly in the framework in the future. However, existing code outside the framework will need to be converted to using the Task class prior to being usable via the CTP.
The .NET Framework has always supported asynchronous operations. However, different mechanisms for supporting exist throughout the framework. While there are at least three separate asynchronous patterns used through the framework, only the latest is directly usable with the new Visual Studio Async CTP. Before delving into details on the new features, I will talk about existing asynchronous code, and demonstrate how to adapt it for use with the new pattern.
Today’s announcement at PDC of the future directions C# is taking excite me greatly. The new Visual Studio Async CTP is amazing. Asynchronous code – code which frustrates and demoralizes even the most advanced of developers, is taking a huge leap forward in terms of usability. This is handled by building on the Task functionality in .NET 4, as well as the addition of two new keywords being added to the C# language: async and await.
Although the Task class provides a huge amount of flexibility for handling asynchronous actions, the .NET Framework still contains a large number of APIs that are based on the previous asynchronous programming model. While Task and Task<T> provide a much nicer syntax as well as extending the flexibility, allowing features such as continuations based on multiple tasks, the existing APIs don’t directly support this workflow.