We’re happy to announce that you can now download an Async Targeting Pack for Visual Studio 11 that lets you target .NET 4 and Silverlight 5. The included DLLs address the previously discussed issue of the Visual Studio 11 Beta compilers being incompatible with the AsyncCtpLibrary* DLLs from the Async CTP;
In a previous post Should I expose asynchronous wrappers for synchronous methods?, I discussed “async over sync,” the notion of using synchronous functionality asynchronously and the benefits that doing so may or may not yield. The other direction of “sync over async”
From time to time, I receive questions from developers which highlight either a need for more information about the new “async” and “await” keywords in C# and Visual Basic. I’ve been cataloguing these questions, and I thought I’d take this opportunity to share my answers to them.
Developers familiar with parallel programming are also familiar with a wide range of potential problems that can occur when practicing the art. One of the most well-known issues is “deadlock,” where two or more operations are waiting on each other to complete in a manner such that none of them will be able to complete.
In .NET 4.5 Beta, the Stream class provides multiple virtual methods related to reading and writing:
- Read, BeginRead / EndRead, ReadAsync
- Write, BeginWrite / EndWrite, WriteAsync
- Flush, FlushAsync
As a developer deriving from Stream,
I get this question a lot:
“Task implements IDisposable and exposes a Dispose method. Does that mean I should dispose of all of my tasks?”
Here’s my short answer to this question:
Lately I’ve received several questions along the lines of the following, which I typically summarize as “async over sync”:
In my library, I have a method “public T Foo();”. I’m considering exposing an asynchronous method that would simply wrap the synchronous one,
Every now and then, I get this question: “is it ok to use nested Parallel.For loops?” The short answer is “yes.” As is often the case, the longer answer is, well, longer.
Typically when folks ask this question,
Are you using the new System.Threading.Tasks.Dataflow.dll library, either from its CTPs or from the .NET 4.5 Developer Preview or Beta? We’d love to hear about it, and if you have time, what your experiences have been (good or bad).
There are several nice API-level enhancements to the Task Parallel Library in .NET 4.6, which you can grab a preview of as part of the Visual Studio 2015 CTP.
.NET 4.5 had a Task.FromResult method.
The .NET Framework blog published this morning a guest post from yours truly on .NET Memory Allocation Profiling with Visual Studio 2012. As you’re trying to improve the performance, throughput, and memory usage of code that uses Tasks,
I can be a bit sensitive when it comes to language and how concepts are conveyed. I think it’s important to be accurate, even if not precise, when describing what something is or how to use it, as otherwise the folks to whom you’re communicating can easily form the wrong mental model for that thing.
Lucian Wischik and I presented an “async clinic” at the MVP Summit in Bellevue this week. The async/await keywords in C# and Visual Basic drastically simplify asynchronous programming, but that of course doesn’t mean that using them is without any gotchas: the goal of the discussion was to highlight some of the key areas in which we see developers struggling with asynchronous development and to help provide guidance on avoiding and overcoming those roadblocks.
These days it’s not uncommon for me to receive an email or read a forum post from someone concerned about a problem they’re experiencing with an async method they’ve written, and they’re seeking help debugging the issue. Sometimes plenty of information about the bug is conveyed,
Recently I was writing an app that processed a bunch of files asynchronously. As with the Windows copy file dialog, I wanted to be able to provide the user with a button that would pause the processing operation.
To achieve that,
Igor Ostrovsky is one of the minds behind the parallel programming support in the .NET Framework. Igor’s recently written a great set of articles for MSDN Magazine to cover “The C# Memory Model in Theory and Practice“.
In both .NET 4 and .NET 4.5, PLINQ supports enumerables with up to Int32.MaxValue elements. Beyond that limit, PLINQ will throw an overflow exception. LINQ to Objects itself has this limitation with certain query operators (such as the indexed Select operator which counts the elements processed),
This is a question I hear relatively frequently:
“I have an async operation that’s not cancelable. How do I cancel it?”
The construction of the question often makes me chuckle, but I understand and appreciate what’s really being asked.