Grant Holliday joins Readify

Yep, its true. Grant Holliday has joined Readify as a Senior Developer here in Canberra. You can find Grant’s blog here which I am sure will become a repository for a wealthy of information. While we are on the subject of blogs I’d like to assert that its not company policy but I personally encourage the other consultants and developers to pick up the dirty habit

Welcome aboard Grant!

Darren points to a great multi-threaded programming site for .NET developers.

Darren Neimke points to a great resource about multi-threaded programming in .NET, I took the time to leaf through some of the content – top stuff and very digestible. One thing that I didn’t see in there was the explaination of the double-check case that often needs to be implemented. This PDF file relates to the issue in C++ but if you look at the first diagram on page three you can see a lock with double check implementation.

This was front of mind for me this week after talking about scenario where their cache gets invalidated and all of a sudden they have a rush on their database. In this case a double check is required because each of the concurrent threads with identify that the cache is empty and even if they do lock while one does the fetch all the other threads are queued up on the Monitor/Mutex waiting to do the same thing.

The double check gets around this by throwing those threads back to fetch from the cache as soon as they get past the lock. You trade off some busy thread synchronisation time for a few thousand database hits – line ball decision?

C# Under Fire (the revenge of C++).

I picked up a link to this post on the Grumpy Old Programmer blog from Chris Sells’ site. Its about the role for C# in the future now that Microsoft has addressed some of the issues that developers had with MC++ with the upcoming release of C++/CLI.

“The” grumpy old programmer is really echoing the sentiments of many C++ programmers out there who have a significant investment in code and their own time, in fact I heard many ‘softies suggest that C# could be dead as a language. Personally I think they are flat out wrong, simply because language choice is more than just about syntax – let me explain.

Before working with C# I had spent time with C, C++, Java, Visual Basic and a few other languages that I would never admit to a recruiter (lest I actually have to work with it again). Each language had its strong points – C for example was incredibly easy to learn but also quite powerful. I always through C++ was a bit of a pig but it was a good step up for C programmers who needed some OO capabilities to express their designs. Java was probably the first language (after Pascal) that I really felt at home in since it was so easy to just write some code into a source file and compile it. And of course Visual Basic hit a productivity sweet spot and in Microsoft-land it was relatively easy to deploy quick and dirty applications with it provided you didn’t get into bed with DCOM.

When I came to .NET I was really after a language that would allow me to target the dominant platform (Windows), give me all the power I needed and in a familiar syntax. The first two requirements weren’t actually met by C#, it was actually the runtime that I fell in love with – but C# was quick and easy to learn and I didn’t have to unlearn things that I would have had to if I decided to make MC++ (at the time) or VB.NET my primary languages.

Now that I’ve been using it for a while and I am generally comfortable with VB.NET and even MC++ its not the language syntax that is making me stay, its actually the alignment of my priorities with the priorities of the Visual C# team. The grumpy old programmer said:

“C# acolytes will no doubt be pampered with IDE features that are denied to other developers (for no technical reason)”

The thing is that there isn’t some overloard telling the various language product teams what they can and cannot do in any given release cycle beyond the general theme of the release. What this really means is if your language of choice doesn’t get the tooling your desperately want, it means the goals of the language team aren’t aligned with yours.

Refactoring support is a classic example. The C# developer community started asking for refactoring support even before Visual Studio 2002 shipped. The Visual C# team listened and now we have Refactoring support in the C# code editing surfaces. The VB.NET community was a little late is asking for refactoring support and so the VB.NET team at Microsoft had to do some fancy footwork to get a third party refactoring tool put into the bundle.

In summary – I think C# will have a long life as a language, not because Microsoft is putting their weight behind it, but because customers want it. I wouldn’t even be surprised if based on future mutations of the language that its usefulness far exceeds that of C++ which in time will be referred to as a grumpy old programmer’s language

A Class A Day: System.AppDomain

If you have been working with .NET for any length of time you will already be familiar with the System.AppDomain class. The name AppDomain is short for application domain and an application domain is an artificial sub-process division that the .NET runtime provides. The idea is that a single process hosting the .NET runtime can split its memory space up into compartments that are isolated from each other.

The AppDomain class is provided as part of the .NET Framework to help manage application domains within your application. So what is there to manage? For your everyday application you would probably use the AppDomain class in much the same way as the Activator class that I covered earlier for creating instances from type strings and what have you. Where it gets really interesting however is putting dynamically loaded plug-ins into a sandbox for security and isolation purposes.

A little while ago I was building a Windows Service which needed to load a whole series of plug-ins written by other developers. The role of the plug-ins were to execute some custom logic on messages routed to them and use a set of APIs that were provided to record information in a database and push other messages back out. While it wasn’t strictly necessary to load each plug-in into its AppDomain it give us a nice side effect of allowing each plug-in developer free reign over their own configuration file, so if they just wanted to using <appSettings /> they could and we wouldn’t need to worry about merging configuration entries at deployment.

While AppDomains are good, they do carry overheads in terms of memory utilisation and even creation. But they can also be a little bit tricky to control from a lifetime point of view. It is almost always a good idea to keep a handle any application domains that you have created, and if you plan to communicate across domains you need to remember that you are essentially dealing with a distributed application which means you are bound by all the rules of .NET remoting – even though you are in the one process.

I don’t think application domain isolation is required (or even desirable) for every plug-in system, but its definately worth understanding what they are and what they can do for you.