Making your C# more effective

Effective C#: 50 Specific Ways To Improve Your C# by Bill Wagner

This is one of those books that lists 50 different issues and pieces of advice for using the programming language – there are variants for C# and Java and many other languages. The items are divied into 6 different chapters.

Chapter one, “Language Idioms” discusses some language level issues – avoiding user defined conversion operators, conditional attributes instead of #if and using “is” and “as” instead of casting. All of the advice seems very reasonnable. The next chapter is on “Resource Management”, and goes into detail about class initialization and then covers the standard Dispose pattern. Immutability and when to use  a value type instead of a reference type are also covered.

Chapter three, “Expressing Designs in C#” is very good and full of lots of good advice. Limiting visiblity and not returning references to internal objects are covered, as are using interfaces instead of inheritance and the difference between interface methods and virtual methods. There are items on defining callbacks using delegates and using the event pattern for notifications. In this mixed bag, there is a discussion about making chunky rather than chatty calls, and also a discussion of co- and contra-variance.

Chapter four is entitled “Working With The Framework”. This covers ordering relationshps with IComparer<T> and IComparable<T> and then moves onto writing parallel algorithms using PLINQ.

Chapter five covers the dynamic type, in a chapter with the rather misleading title of “Dynamic Programming in C#”. There’s a lot of discussion about how dynamic works, and a good explanation of expression trees.

The last chapter, “Miscellaneous”, throws in some advice about boxing and structuring applications as sets of small assemblies.

There were some items that I found very useful. How to use IFormattable to define better string representations for types, minimizing duplicated constructor logic and some of the PLINQ notes in particular. Not a bad book, but some of the advice is either well known or potentially just a matter of opinion.

The author appears on a recent .NET Rocks where he discusses C# 6.0.

Posted in Books | Leave a comment

A good read on concurrency in general (and Java in particular)

Java Concurrency in Practice by Brian Goetz et al

I’d been hearing people mention this book for a long time, and took quite a while to actually get hold of a copy to read. It’s a very good book. Its strength is that is covers the Java concurrency related libraries in good detail, but more than this, there is a lot of supporting material on concurrency in general.

The second chapter of the book covers what it means for something to be thread safe. This term is thrown around a lot by developers, but the chapter makes it clear that there are lots of properties that you may require of a thread safe class, and it is surprisingly difficult to pin down exactly what thread safety is. The next two chapters of the book talk about the sharing and composing of objects, and how this affects their concurrent use. The last chapter of the introductory section covers the basic building blocks, including synchronised and concurrent collections, blocking queues, blocking and interruptible methods, and synchronisers. All of the topics are covered in depth, and I think most people would learn something from reading them.

The second section of the book is about structuring concurrent applications. It covers the notion of tasks, and the connected notions of cancellation and shutdown. The Java mechanism for running thread pools is covered, and this is followed by a discussion of the interplay between GUI applications and concurrency. This has a very well written section on why GUIs are single threaded, answering well the question of why do I always need to move onto the GUI thread before changing GUI elements.

Section three is on liveness, performance and testing. This covers livelocks, deadlocks, performance, scalability, Amdahl’s law and also has a good discussion of testing concurrent programs.

Section four, advanced topics, covers locks and moves on to a discussion of when you might want to use atomic variables and non-blocking synchronisation. There is also a section on the Java memory model and the subtle guarantees of the platform such as how it needs to ensure that publication happens correctly after a constructor runs. There is also a chapter on AbstractQueuedSynchronizer a class which acts a superclass for many of the Java library’s synchronization constructs.

This is a thoroughly interesting book, both explaining the Java library very well and providing a lot of general advice on the topic of concurrency, and is well worth a read.

Posted in Books | Leave a comment

What does better mean for overloads?

This example came up at work.

        class A : I1 { }
        interface I1 { }
        interface I2 : I1 { }
        static void Method(I1 x) { }
        static void Method(I2 x) { }

        static void Main(string[] args)
            Method(new A());

It seems reasonnable that the invocation calls the overload defined on I1, but where in the actual specification is this defined – what does it mean for one overload to be better than another?

The overloads are certainly applicable  and so we need to consider which methods are better. To see which methods are better in a particular parameter position, we need to check whether a conversion is better and this behaviour is defined here.

Posted in Computers and Internet | Leave a comment

Sometimes your worker role needs to run server GC

We were debugging a dump of a Windows Azure worker process at work when it suddenly struck me that the process was using workstation GC and not server GC – I noticed this when looking at the unmanaged stack and noticing that the GC was  running C++ functions in the WKS class and not the SRV class.

Right, I said, I know how to deal with this and went to the worker role’s configuration and changed the setting of the gcServer configuration entry. When I deployed this, the role went into a continuous reboot cycle.

Luckily I came across this post, which discusses how you can write a quick post-deployment script which tweaks the configuration file of the process that hosts your Azure worker.

I must admit that I’d never thought about the hosting of the worker role before, so I logged into the instance and had a quick look. The worker role is deployed to the approot directory on the F drive of the virtual machine.


And the F: also has a mass of other code installed on to it.


This includes the WaWorkerHost process that acts as a host process for your worker’s code (as you can see from processor explorer).


This hosting process is actually managed.


If you want to change properties of the hosting process then you need to change the app.config for this worker process as the PowerShell script from the blog post does.

Posted in Computers and Internet | Leave a comment

A marvellous miscellany

Three different books and articles that I read this weekend across a range of different subjects.

The Little Book of Semaphores by Allen B. Downey

This book looks at various concurrency problems and shows how they can be solved using semaphores. At first I found it slightly strange that the book insisted on using global variables in the solutions (rather than thread locals) which led to a number of strange implementations, but the problems are really interesting and the book explains its solutions well. Semaphore patterns like turnstiles and lightswitch are described and used in the solutions. The book covers fairness and starvation, and mentions a solution by J.P.Morris who showed that is was possible to solve the reader/writers problem without starvation in the presence of weak semaphores using the trick of batching the waiting threads and ensuring that the batches complete in order (which proved incorrect a conjecture by Dijkstra). A quick read, but worthwhile.

Building Cloud Apps with Microsoft Azure

This is a recently released free eBook which covers the various parts of Azure as well as a number of patterns and concepts for Cloud development. Each short chapter has a long list of additional resources which you can easily click and visit. The book gives a concise introduction to large parts of Azure and is well worth a read if you are thinking about moving to the cloud – a world where transient failure and scalabilty make application development a little different from in-house desktop applications.

OAuth tutorial 

I’ve been doing a Coursera course on developing cloud services for Android handheld systems and the application we had to develop used OAuth for the authentication and authorisation. Using OAuth means that the user credentials do not need to be stored on the phone, while at the same time each application can identify itself to the OAuth provider which can prompt for the relevant credentials. In the actual application we wrote for the course, the Spring framework provides the actual OAuth implementation, but as it is always good to understand what is happening under the covers, someone posted a link to this tutorial on the user forum.

It is brief and informative, giving a good overview of the various parts of the protocol.

Posted in Books | Leave a comment

Stop interrupting me

We’ve been using the Quartz work scheduler in a service that I’m maintaining at work. This is a .NET port of a Java application, and while looking over the source code I noticed a pattern that I hadn’t seen used before – the catching of ThreadInterruptedException and the subsequent use of the Interrupt method on a thread, as for example in this file.

Threads have a load of interesting state information associated with them. Previously I’d researched ThreadAbortException, which is associated with the Thread.Abort method. This causes an asynchronous exception to be thrown on the target thread, which is potentially queued if the thread isn’t in a suitable state to throw the exception, and which can use the notion of a pending abort to make sure that the abort is re-thrown when the code exits any catch or finally blocks. This flag can be reset using the Thread.ResetAbort method. Asynchronous exceptions seem to have fallen out of favour in most .NET code, as it is very hard to ensure invariants over your objects if an exception can be thrown at any point in the code – it is impossible to guarantee atomic regions if the presence of asynchronous exceptions unless you start using features like constrained execution regions.

I wasn’t aware before that a Thread can have an associated interrupt pending flag, which the CLR checks before it goes into blocking waits. So this code throws the exception on the line with the Sleep.


So then, how does this all work under the covers? Time to get out the SSCLI source code and have a quick look.

The cpp code in the file sscli20/clr/src/vm/threads.cpp handles the native control of Threads. Each thread object has a field that records whether a user interrupt is pending called m_UserInterrupt. The method HandleThreadInterrupt checks this flag and if we are in a suitable state then it throws the ThreadInterruptedException. This method is called in three other methods – UserSleep, DoAppropriateWaitWorker and DoAppropriateWaitWorkerAlertableHelper (where this last method is called from the non helper method). The first method is called if the user had asked the thread to sleep, and it is DoAppropriateWaitWorker  which does the clever logic when the current thread needs to wait for a HANDLE at the OS level. Waiting is quite a complicated business in Windows – if we want an alertable wait, then queued APC messages can hijack our thread, releasing the wait and this may require us to wait again for a smaller time interval if we are trying to wait with a timeout. These APC messages could come from IO completions for example.

Also in this file is the interesting ReadyForAsyncException which contains the code to see if an asynchronous abort can be delivered to the thread. This involves walking the stack to see if we are inside catch or finally methods. There is also the code in UserAbort which does the logic of a thread abort and which is very complicated – we need to do different things depending on whether we are in managed code or are in unmanaged code for the target thread. We may also need to wait until the thread hits a safe point which will cause it to call CommonTripThread.

The real CLR has the ability to hijack code, by changing the return address on stack frame to regain control. Some of the code to handle this can be seen in excep.cpp around the method IsThreadHijackedForThreadStop.

Posted in Computers and Internet | Leave a comment

See more sharp things

I found a few interesting C# related things over the weekend.

On the open Roslyn codeplex repository there is now a link to a specification for pattern matching in C#. This boils down to a new operator, is, which can be called to determine if a pattern (named via the class on which it is defined) matches, and this operator can also provide a set of out variables that reflect any destructuring in the binding. The standard C# switch statement has been extended to allow cases to be defined that use patterns. The specification can be found here and there is already a mass of discussion here. Unfortunately there isn’t yet an implementation available (though one is promised in a few weeks), and it is always a lot easier to digest these things when you can play with examples.

Delegate and Func always appear similar but disconnected in the .NET framework. Your own delegate type is code generated to IL as a subclass of the inbuilt System.MulticastDelegate type, and the compiler goes out of its way to make the construction of such objects transparent – at its root, a MultiCast delegate is just an instance object (of type object, which can be null if you are referencing a static method) together with a token representing the method you wish to call.

However, you cannot simply convert from one to the other, so the xx3 line in the following code will not compile.

delegate string TestCode(int x);

static void Main()
TestCode xx = x => x.ToString();
Func<int, string> xx2 = x => x.ToString();
Func<int, string> xx3 = xx;

The trick as outlined in this post, is to use the Invoke method on the delegate instance.

Func<int, string> xx4 = xx.Invoke;

As you can see from the IL, this generates a new delegate instance that references the function token of the Invoke method.

L_0039: ldloc.0
L_003a: ldftn instance string ConsoleApplication6.Program/TestCode::Invoke(int32)
L_0040: newobj instance void [mscorlib]System.Func`2<int32, string>::.ctor(object, native int)
L_0045: stloc.2

I’m a big fan of Scala, mainly because the language contains a mass of rather cool language features such as call by name and multiple inheritance via Traits. Recently I did the online Coursera Scala course where there was a module on the for comprehension syntax and how it gets translated into a sequence of maps and filters. It was therefore interesting to see a blog post by Eric Lippert that discusses the more complicated translation that C# specifies for its translation of LINQ expressions.  It is rather interesting that overload resolution in C# has a number of issues when it comes to resolving nested lambda expressions which he references in the article.

As usual, when rereading bits of the Joe Duffy’s excellent Concurrent Programming in Windows,  I noticed some features of the TPL that I hadn’t thought about before. [And also noticed some features mentioned that didn't make it through to the release version of the library such as Task.Current where there is now only an internal InternalCurrent, and mention of a Blocking status in Task.Status]

Tasks that are created inside other tasks are by default independent, but there are configuration options to allow you to attach the children to the parent, so that the parent doesn’t finish until all fo the children have completed.

var task = Task.Factory.StartNew(delegate {
var nestedTask = new Task(delegate
Console.WriteLine(“Finishing 2″);
}, TaskCreationOptions.AttachedToParent);
Console.WriteLine(“Finishing 1″);

Console.WriteLine(“Finished main”);

There is also the .NET version of a promise, a TaskCompletionSource. An instance of this type has a Task property that returns a Task, and the state of this task can be set using methods on the TaskCompletionSource instance. For example, you can set a result, an exception and also set the task as cancelled using the Try… methods.

var tcs = new TaskCompletionSource<int>();


Console.WriteLine(“Finished main”);

Duffy’s book brings together and explains a mass of interesting concurrency observations and is well worth many reads.

Posted in Computers and Internet | Leave a comment