Background

I recently started evaluating MVVM libraries for my client’s project. Though I often share parts of my own unpublished library with a client I had inherited this project and it already had it’s share of commonly-used MVVM types. What it lacked, and I added, was a quickie "message bus" implementation. Not the distributed, enterprise-class sort of message bus, but an intra-app messaging service that decouples senders from receivers. It’s the message bus that I really wanted to replace with a more robust, tested version that must surely already exist in one of the established MVVM libraries.

As luck would have it the first library I downloaded touted a messaging service but, as is too often the case, you get what you pay for. After perusing the code for a bit I could see that the messaging functionality wasn’t thread-safe, a feature I require. My app is a multi-threaded WPF app with both managed and native threads and takes pains to keep work off the UI thread in order to achieve smooth and somewhat real-time rendering of data. Wrapping the library’s messaging code for synchronization would be easy, but it doesn’t feel like fine enough granularity of locking for good performance.

Weak Action is Weak

Another driver in looking for an established library is that my quickie message bus implementation holds references to subscribed listeners. Not really a problem unless a listener fails to unsubscribe, in this case the listener will never be garbage collected. I consider that an undesirable situation. So I took a look at the above library’s implementation of a weak action; I quickly saw that this code used not a weak reference but a strong reference; it suffered the very problem it purported to fix. FYI, I did verify that the problem is known to the library’s author.

Now, at this time I haven’t finished evaluating libraries, and this was a bit of a rough start. Maybe I’ll just set aside some time to come up with a solution myself. Like… now.

An Elegant Solution (maybe…)

The problem I’d like to solve is that Action holds a reference to the target object of non-static delegates, preventing that target from being GC’d. The most elegant solution would allow me to simply replace my use of Action and Action<T> with an implementation that holds only a weak reference to the target. And here it is:

   1: static Action CreateWeakAction(Action action)

   2: {

   3:     if (action == null)

   4:         throw new ArgumentNullException("action");

   5:  

   6:     // If it's a static delegate there's no need to create a weak reference.

   7:     if (action.Target == null)

   8:         return action;

   9:  

  10:     Type type = action.GetType();

  11:     WeakReference targetRef = new WeakReference(action.Target);

  12:     MethodInfo method = action.Method;

  13:  

  14:     return () =>

  15:         {

  16:             // Don't reference 'action' in this lambda expression.

  17:             object target = targetRef.Target;

  18:             if (target == null)

  19:             {

  20:                 // Target was GC'd; don't do anything. (Ick.)

  21:             }

  22:             else

  23:             {

  24:                 Delegate.CreateDelegate(type, target, method).DynamicInvoke();

  25:             }

  26:         };

  27: }

Using CreateWeakAction is pretty easy:

   1: Action action = CreateWeakAction(() => receiver.DoSomething(42));

   2: // Time passes...

   3: action();

Now the target (‘receiver’ in the above example) is free to be collected, but I have a new Action delegate returned from CreateWeakAction that will not be collected unless I release my reference to it. More than that, I have no way of telling whether the delegate I’m holding no longer has a live reference to the target. I could conceivably change my Action to a Func<> that returns an indicator of whether the target was GC’d, but that would require me to actually call the delegate to determine its state. And I would lose the elegant drop-in replacement I was hoping for.

A More Measured Solution

Setting aside my personal desire for elegance solutions, the actual requirements I’m looking to satisfy in my message bus are twofold: 1) don’t hold a reference to the target listener and 2) don’t hold unnecessary objects in the heap. A weak action implementation that satisfies these needs might look something like this:

   1: class WeakAction

   2: {

   3:     public WeakAction(Action action);

   4:     public bool IsTargetAlive { get; }

   5:     public WeakActionInvocationResult Invoke();

   6: }

This would allow me to create an instance of my weak action, invoke it’s behavior when needed, and check whether the target is still alive so that I can cull stale instances from my message bus implementation. And, thanks to an uninterrupted morning at my local coffee joint I have what I wanted. You may note that I’ve made an abstraction for invoking instance delegates; this makes that code more easily reusable for generic implementations (e.g., WeakAction<T>).

   1: internal class WeakAction

   2: {

   3:     private readonly InvocationAgent _instanceAction;

   4:     private readonly Action _staticAction;

   5:  

   6:     public WeakAction(Action action)

   7:     {

   8:         if (action == null)

   9:             throw new ArgumentNullException("action");

  10:  

  11:         if (action.Target != null)

  12:         {

  13:             _instanceAction = new InvocationAgent(action);

  14:         }

  15:         else

  16:         {

  17:             _staticAction = action;

  18:         }

  19:  

  20:         Debug.Assert(_instanceAction == null || _staticAction == null);

  21:         Debug.Assert(!(_instanceAction == null && _staticAction == null));

  22:     }

  23:  

  24:     public bool IsTargetAlive { get { return IsStatic || _instanceAction.IsTargetAlive; } }

  25:  

  26:     private bool IsStatic { get { return _staticAction != null; } }

  27:  

  28:     public WeakActionInvocationResult Invoke()

  29:     {

  30:         if (_instanceAction != null)

  31:             return _instanceAction.Invoke();

  32:  

  33:         _staticAction();

  34:         return WeakActionInvocationResult.Invoked;

  35:     }

  36: }

Note that I’ve made an optimization for static delegates—there’s no need to incur the cost of dynamic invocation in that case because a static delegate has no target, therefore it won’t prevent anything from being GC’d.

Now imagine we have a messaging implementation that needs to track listeners with Action delegates but would rather not keep a reference to listeners forever if they happen not to unsubscribe. We can now create an instance of WeakAction and use it to invoke the listener’s Action when we wish; we can also query the WeakAction on occasion to determine whether it still has a live listener.

Finally here are the missing parts to make it work, the interesting bits. What makes this work is pulling apart the delegate into its component parts, holding the target part with a  weak reference, and reassembling the parts into a delegate only when needed to invoke the original delegate. No reference to the original delegate is held.

   1: internal enum WeakActionInvocationResult

   2: {

   3:     Invoked,

   4:     Collected,

   5: }

   6:  

   7: internal class InvocationAgent

   8: {

   9:     private readonly Type _type;

  10:     private readonly WeakReference _targetRef;

  11:     private readonly MethodInfo _method;

  12:  

  13:     public InvocationAgent(Delegate action)

  14:     {

  15:         Debug.Assert(action.Target != null, "Expected a non-static delegate");

  16:  

  17:         _type = action.GetType();

  18:         _targetRef = new WeakReference(action.Target);

  19:         _method = action.Method;

  20:     }

  21:  

  22:     public bool IsTargetAlive { get { return _targetRef.IsAlive; } }

  23:  

  24:     public WeakActionInvocationResult Invoke(params object[] args)

  25:     {

  26:         object target = _targetRef.Target;

  27:         if (target == null)

  28:             return WeakActionInvocationResult.Collected;

  29:  

  30:         // Don't keep a reference to this delegate.

  31:         Delegate.CreateDelegate(_type, target, _method).DynamicInvoke(args);

  32:         return WeakActionInvocationResult.Invoked;

  33:     }

  34: }

I’ll leave it as an interesting challenge to the reader to implement WeakAction<T>. Here’s what it might look like:

   1: class WeakAction<T>

   2: {

   3:     public WeakAction(Action<T> action);

   4:     public bool IsTargetAlive { get; }

   5:     public WeakActionInvocationResult Invoke(T t);

   6: }

Grab a cup of coffee and have at it. Please note: I’ve tested only on the desktop CLR, not Silverlight or Phone, so caveat emptor.

What follows are some loose notes I took during the event; this isn’t intended to give you the experience of actually being there. The featured speakers were Pete Blois, a Program Manager on Expression Blend; and Jaime Rodriguez, a Technical Evangelist for Windows Phone.

Notable tidbits that came out during the presentations:

- Pete on the yet-to-appear Pivot and Panorama controls: “Those controls are coming.”
- Jaime on future changes to the platform: “We’re not cutting a lot of things any more.”
- The Bing Maps control will not require a paid license. (Jaime)

Pete Blois
Pete demonstrated Expression Blend for Windows Phone 7. Blend for WP7 has improved quite a bit since the first release, most notable to me being the arrival of a full plate of Behaviors in the asset pane. Also new is the device tab with which you can change the theme (colors), device orientation (landscape and portrait), and whether you want to preview on the emulator or a device.

Pete did some quick demos of implementing page fly-out transitions and addressing orientation changes using Visual State Manager and Fluid Layout.

Blend also has new tooling in the properties pane for the ApplicationBar and its icons. (You’ll find that you can’t access this by selecting the ApplicationBar in the Objects and Timeline pane; you need to select the PhoneApplicationPage (the root element) and find ApplicationBar under Common Properties.) There you can adjust the colors, buttons, menu items and so on. Unfortunately we can’t use x:Name on ApplicationBar or bind to its properties; ApplicationBar is a wrapper over the native OS’ app bar–you can’t bind because it’s not a Silverlight control owned by your app.

Performance of animations can be an issue, and Pete advises using storyboards as well as render and perspective transforms–these happen on the rendering thread (which is a high priority thread). Don’t animate on width, height or layout properties, as these cause invalidation of the layout.

Jaime Rodriguez
Jaime discussed the core Silverlight controls: WP7 has those controls that make sense on the phone. Controls such as DataGrid make less sense in the mobile environment due to the lack of screen real estate. The Beta release is still missing some core controls, and tombstoning should see some improvement, but “We’re not cutting a lot of things any more.”

On the Panorama control (not in the Beta): Panorama should have 3 panels or more of content, otherwise it’s a bit silly to use it; more than 6 or 7 panels is a bit large and unwieldy. Panorama is good for exploring content, and imitates a continuous horizontal landscape that you can explore; it wraps around to the first panel if you swipe past the last one. Interestingly, Panorama does not have an app bar.

On the Pivot control (not in the Beta): it’s basically a slick tab control. Each page in the Pivot is related, but they don’t necessarily need to show the same content.

Bing maps control (not in the Beta): There will be a WP7-specific control for Bing maps. You will need to acquire and app ID to use this (as you do with Bing Maps in general) but you won’t have to pay for using the map. The map will be programmable, support gestures, and ship by RTM.

Jaime demonstrated UI navigation, especially the behavior of the back stack. I won’t get into this, as Yochay Kiriaty has a series on app activation/deactivation, tombstoning and the application execution model here.

Summary
All in all, it was a fairly informative two hours of information. I look forward to the next event on September 1st.

    new MyObject().LongRunningMethod();

as well as this scenario: 

    MyObject o = new MyObject();    o.LongRunningMethod();

Here we’ll discuss how this could become a problem. Frankly, it’s pretty easy to cause the problem, but I think it generally involves some ugliness on the part of software design or implementation, largely involving clean-up of fields when the instance is finalized. 

Don’t Try This at Home

I don’t think it’s likely you’ll see a lot of code that does this, but here’s one way to run afoul of your object going way: export a reference to a field that the object cleans up when it’s finalized. You can export the reference, say, by making that field visible through a property. Exposing a field that you’re going to clean up in the finalizer would be an easy way to create a coupling between your object and other (arbitrary) client code that has no knowledge of your object’s life span. 

Call Stack Antics

Another way to invoke the potential problem is to lose your “this” reference on the call stack. The code below manages to lose the “this” reference by passing a field to the helper method rather than allowing the helper to access the field directly via its own “this” reference. When the helper tries to access fs.Length an ObjectDisposedException is thrown. 

Why does this throw? Well, the last live reference to the instance was lost when LongRunningMethod passed _input to Helper. Essentially we’ve again exported the field value from the instance and no longer hold a reference to the instance, allowing the GC to finalize it. Helper is left holding a reference to an object that has been finalized. 

Note: Again, you will not see this behavior in a debug build. When running code marked as “debug” the JITter extends the lifetime of the local object to the end of the method. So you will not see this effect if you’ve compiled with the /debug flag. 

    using System;    using System.IO;

    // Ugliness ensues.
    sealed class MyUglyObject
    {
        public MyUglyObject(string inputPath)
        {
            // Real production code would likely not delete the file when done...
            // ...but this is a sample app.
            _input = new FileStream(Path.GetTempFileName(), FileMode.Open, FileAccess.Read, FileShare.Read);
        }

        ~MyUglyObject()
        {
            if (_input != null)
            {
                _input.Close();
                _input = null;
            }
        }

        public void LongRunningMethod()
        {
            Helper(_input); // Our last reference to 'this' (implicit).
        }

        private void Helper(FileStream fs)
        {
            // A long-running method can easily experience a garbage collection
            // before returning. This one happens for force it to occur.
            GC.Collect();
            GC.WaitForPendingFinalizers();

            // Ka-boom!
            long inputSize = fs.Length;
            // ...
        }

        private FileStream _input;
    }

    class Program
    {
        static void Main(string[] args)
        {
            new MyUglyObject(@"....readme.txt").LongRunningMethod();
        }
    }

Can You See It?

As you can see above it takes a bit of effort to cause the code to blow up. If Helper had used _input.Length instead of taking a parameter the problem would not exist. 

But, what I find a bit creepy about the above code is that if Helper were a static method it would seem respectable: 

    private static void Helper(FileStream fs)
    {
        // A long-running method can easily experience a garbage collection
        // before returning. This one happens for force it to occur.
        GC.Collect();
        GC.WaitForPendingFinalizers();

        // Ka-boom!
        long inputSize = fs.Length;
        // ...
    }

At first glance it now looks like helper is a normal static helper function, as is likely seen in code bases across the world. It doesn’t need a “this” reference, it takes a reference to the object it uses, everything appears fine on the surface. Would you see the “this” reference being lost by the code calling Helper in a code review? I’m not so sure I would have until recently. 

There’s a regular idiom in C# in which we call a method on an object instance that we’ve created inline:

    new MyObject().LongRunningMethod();

There assumption may be an assumption that the lifetime of this instance of MyObject extends at least until LongRunningMethod returns, but this isn’t necessarily true. This same assumption is often made about local references to objects:

    MyObject o = new MyObject();    o.LongRunningMethod();

However, in both these cases the object instance may be collected before LongRunningMethod returns.

Does this really happen?

Yes, it can and does. The code below exercises this behavior. When you run it you will see the following output, indicating that the object was collected and finalized before LongRunningMethod returns:

    Using release build
    Inline
    Entering MyObject1.LongRunningMethod().
    Finalizing in ~MyObject1().
    Returning from MyObject1.LongRunningMethod().     Local reference
    Entering MyObject1.LongRunningMethod().
    Finalizing in ~MyObject1().
    Returning from MyObject1.LongRunningMethod().Note: You will not see this behavior in a debug build. When running code marked as “debug” the JITter extends the lifetime of the local object to the end of the method. So you will not see this effect if you’ve compiled with the /debug flag.

Note also that this article also assumes we’re using CLR 2.0. Future versions could obviously behavior differently.

Here’s the code. Just drop it into test.cs, run csc test.cs, and execute test.exe.

    using System;

    sealed class MyObject
    {
        ~MyObject()
        {
            Console.WriteLine("Finalizing in ~MyObject1().");
        }

        public void LongRunningMethod()
        {
            Console.WriteLine("Entering MyObject1.LongRunningMethod().");

            // A long-running method can easily experience a garbage collection
            // before returning. This one happens for force it to occur.
            GC.Collect();
            GC.WaitForPendingFinalizers();

            Console.WriteLine("Returning from MyObject1.LongRunningMethod().");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
    #if DEBUG
            string build = "debug";
    #else
            string build = "release";
    #endif
            Console.WriteLine("Using {0} build", build);

            // Try it both ways.

            Console.WriteLine("Inline");
            new MyObject().LongRunningMethod();

            Console.WriteLine();
            Console.WriteLine("Local reference");
            MyObject o = new MyObject();
            o.LongRunningMethod();
        }
    }

Is this a problem?

Generally, I’d say it’s not a problem. Once it has begun execution, LongRunningMethod doesn’t need the original object reference unless it’s making reference to that instance. In that case the GC won’t be able to collect the object.

I’ll discuss how to make it a problem in Part 2 of this article.

As the discussion turned to security issues I was reminded of a security issue I pointed out to a colleague back in, well, I believe it was the first half of the 90′s. The issue: the attack vector brought about by speaker-independent voice recognition. The scenario: the disgruntled office worker running through the cubicle farm, shouting “File. Close. No! File. Close. No!”

It amuses me to think that perhaps the new ribbon-and-pearl command structure of Office 2007 apps has gone a long way in negating that issue.

• Improve Developer Productivity
• Manage the Application Life Cycle
• Employ the Latest Technologies

After all, true geeks are more interested in the latest technologies than in process, right? Of interest to me in the Orcas release of Visual Studio, I see:

LINQ (pp. 8,13)

I admit I’m a bit of a Luddite when it comes to language features. It took me a while to see that C#’s “using” syntax was clearly a good thing. What do you expect from a C++ developer whose first C++ compiler was a cfront translator–we didn’t have C++ compilers back then. Don’t give me syntactic sugar–let me do it the hard way! Give me a preprocessor!

All the same, LINQ seems to be a boon to anyone who wants to query over structured data. I’ll likely adopt it in (personal) record time.

Further support for building WPF applications (pp. 5, 19)

Debugging support for WPF. I have to wonder what that will look like. Will I be able to step through XAML?

New APIs in Window Vista (p. 6)

Seriously, are there really “more than 8,000 new native APIs available in Windows Vista?” My brain hurts. Maybe I need to buy a llama farm and learn to live the simple life. I mean, I started programming Windows code in 1991. That’s later than many, earlier than most. Dear God, I even digested Kraig Brockschmidt’s book, Inside OLE2! Gah! Is my brain going to fill up and return E_OUTOFMEMORY? And will that be a fatal error?!

New managed add-in model (pp. 14, 16)

I’ve seen some tough questions asked about how to control the impact of rogue add-ins in a managed application. The CLR Add-In Team Blog indicates someone at Microsoft is working at addressing these issues, as does this white paper.

Lightweight reader/writer lock with deadlock-free upgrade support (p. 14)

Hmm, a slimmed-down read-writer lock that doesn’t support recursion. This sounds a bit like what Jeffrey Richter describes in CLR via C# (second edition, pages 642-643). I can’t wait to compare Richter’s version in Wintellect’s Power Threading library with what Reflector tells me about Orcas’ System.Threading.ReaderWriterLockSlim. It should be an educational experience.

New IO types that expose almost all pipe functionality provided by Windows (p. 15)

It’s about time.

A trace listener for ETW (p. 16)

Woot! High-perf event tracing!

Peer Networking Classes (p. 17)

I don’t know how much of the P2P APIs this might encompass, but it’s definitely an area I’ll be experimenting with. I expect we’ll be seeing some very cool apps born out of this space. Apps we haven’t thought of yet.

Woof. As usual my eyes are bigger than my stomach. I hope to have time to explore at least a few of these areas.

Yet it’s a bit renewing, helping one project through RTM and SP1, then picking up and beginning fresh on something totally different with a completely different set of people. It’s interesting how from one project to the next people vary so much. It’s like they’re wired differently.

Aside from the pleasure of meeting and working with new people, I also enjoyed this view from my desk in recent months. (Sorry about the cell phone picture quality.) Can you find the Space Needle?

If experience is any indication my desk at my next assignment will likely face a beige wall in building 41 instead of downtown Seattle. But it involves some pretty cool software. Oh, well, you take the good with the bad.

It doesn’t. It’s simply not type safe.

The Problem

Here are the types from the above-mentioned post; I’ve added the FavoriteColor property for later discussion:

For discussion’s sake, here’s the declaration of the method in question:

FetchContact‘s signature indicates that it can return a Contact via the contact parameter.

And now the code the poster wants to use:

It certainly appears that the calling code desires to get a Recipient from the call to FetchContact, but that’s not within the interface contract of FetchContact. FetchContact returns a Contact via its contact ref parameter.

Try, Try Again

Now, it’s true that the following fragment of code works; it adheres to the interface contract specified by FetchContact:

Well, of course that works, we’ve modified the code to pass a ref Contact as specified by the method signature. But why doesn’t the first?

Type Safety

Let’s try a different tack. To simplify, ignore for the moment that we’re looking at a ref parameter. Instead, consider it an out parameter. And we’ll also assume that there are more types derived from Contact, for example:

Now, consider again, what type FetchContact is returning here as an out parameter?

The correct answer is “We’re not sure.” FetchContact could return a Contact, a Recipient, a Sender, or any other type derived from Contact. The problem of the original code is that it assumes that FetchContact is returning a Recipient and tries to coerce the type. This would not be typesafe as we don’t know that the object returned is actually a Recipient.

Consider what happens when FetchContact is (legally) implemented like this:

The object passed back to the caller is obviously a Sender, not a Recipient. The only way for the caller to treat the returned value as a Recipient is to break type safety, and C# generally does not let one do this.

Hypothetically Speaking…

What if C# did let us ignore type safety? Let’s suppose that this code could compile and execute:

Now FetchContact has returned a Sender that we’ve coerced into a Recipient reference. Not good. It might execute right up until we use the FavoriteColor property. Think about it. FetchContact returns an instance of Sender, which we’re treating as a Recipient. But the Sender type doesn’t have a FavoriteColor property. What would happen then? It would surely crash or return invalid data, just as we would see in C++.

C# prefers type safety and doesn’t allow this to happen. That’s a good thing.

But it’s a ref, Not an out Parameter

I believe this is the cause of the confusion around this issue. ref parameters are both in and out parameters. Noone would mind if we passed a Recipient instead of a Contact as an in parameter so why can’t we do it here? Because ref parameters, like out parameters, have a stricter requirement: you cannot assume the returned type is a more derived type than the parameter’s given type. To do so would not be type safe. The parameter in question must be a ref Contact.

But This Works in Other Languages

This may sometimes work in languages that allow you to subvert type safety (most famously C and C++). It will only work so long as you are lucky about your class layouts or your assumptions remain true. When either class layouts or your assumptions change your code will no longer work.

Here’s an example in C++. I run it in the debugger and it crashes on line 20 due to the type coercion done on line 41. This should not come as a surprise.

 Hope that helps.

In what I would describe as a cockpit I found a something like a display panel which was flashing this message:

Exception in thread “nav” java.lang.ClassCastException: java.lang.Double
at NavigationWaypoint.<init>(NavigationWaypoint.java:10)
at FindWaypoint.FindNextWaypoint(FindWaypoint.java:94)
…

Obviously this sparked my curiosity! In looking around the cockpit I discovered a bit of paper–more like mylar, really–clutched in what for now I’ll call the unfortunate being’s hand. I liberated this piece of paper and found printing on it. I was shocked to see what the paper showed:

What a tragedy! Clearly the author of this code (presumably an inexperienced alien programmer) had errantly designed the instance constructor to take an Object rather than a String. In doing so the coder then needed a typecast in order to coerce the Object to a String in order to set the name field.

I don’t know about most, but on my planet such use of a typecast is a pretty strong clue that the programmer should look around to see why the typecast is necessary; it may be indicative of a design error.

In fact, in this case it is a design error. The NavigationWaypoint class has a name field that contains a string, yet the constructor allows the caller to pass in an object of any type. This unfortunate error and the use of a typecast caused the error to manifest itself during execution of the code; obviously some other code passed in a Double rather than a String, probably a simple coding error. If the constructor had been coded to accept a String this coding error would have been caught at compile time rather than during execution, saving this little fellow the exasperation of debugging on the fly and waking up frozen on a strange planet. If only the constructor had been coded to correctly represent the type’s data….

(This post was inspired by a true story that had nothing to do with navigation.)

using System;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        // 'num' lives on the main thread's stack.
        int num = 0;
        Console.WriteLine("initial num=" + num);

        Thread thread = new Thread(
            delegate()
            {
                // Yet this delegate running on a different thread with
                // it's own stack has access to 'num' as well.
                num = 42;
            });

        thread.Start(); // Start the worker thread.
        thread.Join();  // Wait until the worker thread has finished.

        Console.WriteLine("final num=" + num);
    }
}

It’s pretty simple. This program declares and initializes a variable named num, creates and starts a thread that will set num to a different value, then waits for the thread to to complete. In the program’s output we see that num has indeed been set to 42. Here’s the view from the command line:

F:tmp>csc Program.csMicrosoft (R) Visual C# 2005 Compiler version 8.00.50727.42for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

F:tmp>Program.exeinitial num=0final num=42

Okay, that’s as expected. But wait–num lives on the main thread’s stack. How is it that the second thread we’ve created has access to num? num isn’t on the second thread’s stack and it would be a pretty scary thing if the second thread had direct access to the first thread’s stack. All sorts of mayhem could ensue. Providing access to another thread’s stack isn’t exactly the sort of thing we want to happen in managed code.

Chicanery?

As it turns out, though it appears that num is a stack variable in the main method it is not. What we’re experiencing here is a convenience provided by the compiler. Or rather, a trick. A sleight-of-hand. An illusion. num doesn’t actually live on the stack.

In fact, the compiler has made num a field in a compiler generated class so that it can be made available on the heap to the delegate. Here’s the compiled code, courtesy of .NET Reflector:

[CompilerGenerated]
private sealed class <>c__DisplayClass1
{
      // Methods
      public <>c__DisplayClass1() { }
      public void <main>b__0()
      {
          this.num = 0x2a;
      }

      // Fields
      public int num;
}

The compiler has given our anonymous delegate method a name: it’s <main>b__0() on this compiler generated class. As a member of this class it obviously has access to num. The illusion is completed by fitting out the Main method so that it has an instance of <>c__DisplayClass1 to use:

private static void Main(string[] args)
{
      Program.<>c__DisplayClass1 class1 = new Program.<>c__DisplayClass1();
      class1.num = 0;
      Console.WriteLine("initial num=" + class1.num);

      Thread thread1 = new Thread(new ThreadStart(class1.b__0));
      thread1.Start();
      thread1.Join();

      Console.WriteLine("final num=" + class1.num);
}

So now our Main method has an instance of an object on the heap and can set num to zero since num is a public field on the compiler generated class.

And so, both threads are accessing a variable–not on the stack, but on the heap and accessible to both threads. This helpful behind-the-scenes work by the C# compiler allows us to keep the simplicity of the original code in this example; otherwise, we’d need to implement something like what the compiler has done for us. 

[Edit: Fix up formatting.]