Bernhard Glück

Beta 2 of Visual Studio 2010 has arrived and is available for download for just about anyone to grab.

I’ve played around with this release for a week now ( Msdn release was a few days prior to public availability )
and so far my feelings are best described in romantic terms: Love at first sight.

There are so many great features/improvements that I just don’t know where to begin, but I’ll try anyway.

For the first time since Visual Studio 6 back in the 90s, online help is fast again. Microsoft rewrote the complete help
system and based it around a small local Web server that serves Javascript enriched help content.
Hovering on some identifier, pressing F1 and waiting for the new context sensitve help to pop up takes about 0.5 seconds
on my local machine.

TFS Basic is great. I stayed clear of TeamFoundation server for the last releases since my initial evaluation turned out that it did
not offer much over other tools, but required insane ammounts of hardware and installation/administration effort that just were
not easily recouped by it’s functionality.

TFS Basic installs easy, fast ( 20 minutes for me without any error whatsoever ) and runs even on client OS editions if you’re into that.

UML Modelling support has finally arrived, of course it’s the first release, and code generation support seems not to be on the agenda, but
for some fast and simple diagramming it’s certainly enough.

The C++ compiler supports a few things from the upcoming revised standard, like the auto keyword, lambda functions and nullptr.
TR1 support has also matured and so we can write even better standard compliant code right now.
Performance of C++ intellisense seems also much better, especially with larger codebases.
Also C++ finally uses Msbuild for it’s build system as well as project files. So codebases that mix C++ with C# are now much easier to handle
in build environments.

For C# we have of course the new dynamic dispatch features, as well as optional and named parameters, and better co/contravariance support for generics.
I still don’t like dynamic dispatch support, simply because I think it will be used for all the wrong reasons, and because it throws out a lot of the investment
in static source code analysis technology, and proofing program correctness.

On the runtime side of things, of course we have additions to WCF/WPF a completly rewritten Workflow Foundation, and many other small things like
a few conveniance methods ( string.IsNullOrWhiteSpace ).

The Task Parallel library is a godsend, but I am still in fear of it’s usage patterns. I see a lot of developers who are not experienced in multithreading
just use things like Parallel.ForEach or PLINQ because it’s so damn easy thereby ignoring the concurrency issues, producing code that will just fail
at unpredictable times.
At least we have some by default threadsafe collections now, but the performance implications of those must not be overlooked, collections are rarely the
right place for some last effort “catch all” synchronization.

Things like native support for Memory Mapped files, the inclusion of Code Contracts which were previously available as an addon, as well as conveniance
data structures like tuples or sets round off the framework itself.

The client GC can now do parallel garbage collections under certain circumstances ( during full collections a certain number
of allocations can be still be done while the collection is running ).

The server GC does not support this apparently because of lack of development time, which is really not nice, since especially there it would have resolved certain issues in long running applications
that have bitten me in the past.

Last but not least ADO.NET Entity Framework is in it’s second release, supports forward engineering finally, and generally seems much more mature now, time to take it for a spin in the next few days.

All in all a great release, and the nice WPF UI of Visual Studio just make working that little extra spicy, so in conclusion: I really like it !

I did some investigation of the new System.Collections.Concurrent namespace today, because I considered using them for my private server project. I know collections are not the place to put synchronization, but in my use case I believe it’s justified, as it is the classic producer/consumer pattern.

My custom server is built to handle a lot of concurrent tcp/ip connections and receive and send data constantly.
It will also likely run on machines with at least 8 cores, possibly a lot more. Thus I need a collection ( mostly a simple queue ) that is high performance and scales well with the number of physical cores.

However after looking at the implementation of ConcurrentQueue in the .NET 4.0 Beta1 release I had to rule them out. While certainly a very clever piece of code, they still rely on the the dreaded monitor and spinlocks. Therefore as soon as you go over the 4 core mark ( depending CPU architecture of course ) they will not scale well. This is of course no problem for software that just uses them for a little amount of data, but in my server they are under high load all the time.

So for now I still have to use my own queue that uses atomic cpu operations for doing implicit synchronization.
While this lock free queue implementation certainly has worse performance, it scales very nicely on more than 4 cores under high load.

No, I am not playing the game, ( that should be left to way smarter people than me ) but fiddling around with Microsoft CHESS a product by their research group, that is going to be included in Visual Studio 2010. Right now it’s available in Beta form and it simply rocks.

The basic premise is that a new Test Runner for the Microsoft Testing Framework will run your unit tests that make use of multiple threads a large number of times with different thread interleave patterns, and thus detecting many kinds of threading bugs in your code.

After it has found a thread interleave sequence that will make your unit test fail, you can save this information and add it to the unit test itself, making your unit test reproduce the problem each time reliably.

This is simply a godsend, and the magic does not stop there.

While debugging the running unit test you can also break on any thread preemption which are very likely the spots in your code that actually contain the code that is the root cause of your bug.

So give this awesome tool a try, and write even better multithreaded code.

Microsoft Chess