Reactive Programming in C#: ReactiveObject

The company I work for has been using reactive programming for quite sometime, and I added our implementation to CLINQ a couple months ago (You can find it in by getting the latest source and finding the Reactive namespace.)  I noticed that Josh Smith, (who has an excellent WPF blog)  just posted something along the same spirit.  Of course, I quickly spammed the comments in his blog about ReactiveObject.  I figured I should give an explanation of how it works, and the various issues that you must deal with when solving this problem.

The infamous INotifyPropertyChanged requires classes to fire an event in each property’s setter with a string matching the property name.  Very often, other classes want to observe those property changes and execute code as a result. These other classes subscribe to the PropertyChanged and then have to examine the EventArgs and an inevitable switch statement or lookup table is used to map to an appropriate handler. This leads to hard coded strings, and messy messy code.  However, the spirit of this type of “reactive programming” is an excellent way to decouple your code, and is awesome for designing object models that hookup to WPF, or any other UI framework for that matter.  Here’s where ReactiveObject comes in which, I hope will change how you architect your front end applications.

Here’s an example of a Person class that follows this model. In this style of programming, an object wants to execute some code, or react, when properties change on itself or some other object.  (ReactiveObject implements INotifyPropertyChanged for you.) Let’s say we have Person object, and that person has Brother property which, of course, is another Person.  Now, whenever we change the Brother of a person we want to calculate the age difference between the two siblings.  Also, if someone changes the person’s age, we would need to do the same thing.  (I’m not going to deal with the circular reference situation for the sake of brevity,  but don’t worry that works too.)

Here’s how you would implement the Person class to make this happen.  (Explanation below)

        public class Person : ReactiveObject
            static Person()
                var dependsOn = Register<Person>();

                dependsOn.Call(me => me.OnMyAgeChanged())
                    .OnChanged(me => me.Age);

                dependsOn.Call(me => me.OnMyBrothersAgeChanged())
                    .OnChanged(me => me.Brother.Age);

                dependsOn.Call(me => me.UpdateAgeDifference())
                    .OnChanged(me => me.Age)
                    .OnChanged(me => me.Brother.Age);

            private int _ageDifference;
            public int AgeDifference
                get { return _ageDifference; }
                    if (value == _ageDifference)
                    _ageDifference = value;

            private int _age;
            public int Age
                get { return _age; }
                    if (value == _age)
                    _age = value;

            private Person _brother;
            public Person Brother
                get { return _brother; }
                    if (value == _brother)
                    _brother = value;

            //Executed if this.Age changes, or if this.Brother.Age changes!
            private void OnMyAgeChanged()
                Console.WriteLine("My age is now", this.Age);

            //Executed if this.Brother changes, or if this.Brother.Age changes!
            private void OnMyBrothersAgeChanged()
                Console.WriteLine("Brothers age is now", this.Brother.Age);

            //Executed if this.Age, this.Brother, or this.Brother.Age changes!
            private void UpdateAgeDifference()
                this.AgeDifference = this.Age - this.Brother.Age;


The real magic is in the static constructor of the Person object. This sets up how this object will react to property changes.  The first thing you do is call Register<Person> which returns a little object that you use to do registrations.  You use this registration object to define your relationships.  It uses a simple fluent interface that says: call this function on the object when a particular set of properties change.  Each lambda takes a me parameter.  Conceptually, me is the same as this if you ignored the fact that you’re in a static constructor. This is very important to the performance of the system, but understandably a little confusing at first.

The first example above says:  call OnMyAgeChanged whenever someone sets my Age property.

The next, and more interesting, example says:  call OnMyBrotherChanged whenever you set my Brother property, or if the Age property on my Brother changes.  The lambda expression you pass to OnChanged gets analyzed to any depth, and creates subscriptions on all the objects it encounters.  Also, brother can be null and nothing will break.

The final example shows how you can calculate something that depends on multiple values.  In this case the system will call UpdateAgeDifference when either the person’s Age, the person’s Brother, or the person’s Brother’s Age changes.  This means that your calculation will always be current no matter what changes underneath you.

Pretty nifty, no?  I’ve been part of team that has built an application on exactly this style of programming, and it has been a godsend.  All of your code is very decoupled, and information just flows through your program.

There are a few things to mention as to what’s going on behind the scenes.  First, all event subscriptions are weak and rely on CLINQ’s super fast property change manager.  (The one provided by WPF is slow.)  Next, the registration is done in the classes static constructor which means that there is only a one time hit for the lambda analysis and dependency map generation.  Also, you’ll notice that the handlers also require lambdas, which are open delegates rather than closures.  (Hence, this is why we have the me parameters.)  This is an important side effect of doing registration in the static constructor as closures will cause leaks, and ye olde memory fragmentation.

High Performance Property Changed Weak Event Notifications for C#

I’ve been doing a lot of work on Continuous LINQ (CLINQ), and by that I mean I’ve written 90% of version 2.0.  CLINQ is being developed for a large scale and real life WPF application that must be robust and high performance.  I plan to post quite a bit about the internals if I don’t get lazy.  I’ve had to put in so much trickery and ran into so many esoteric things that I figure passing the learning on would be worthwhile.

Kevin Hoffman, the project administrator, and my partner in crime for CLINQ posted about my original implementation for weak events early on in the development of CLINQ 2.0.

In a WPF application, INotifyPropertyChanged is king.  All objects must implement it in order to be consumed by the UI.  There’s lots more to discuss about this interface that I’ll save for other blog posts.  For now, what’s important is how WPF utilizes this interface.   Whenever a property on an object is data bound to control in WPF, the control must know when the value of that property changes in order to update the UI.  This may sound straight forward, since INotifyPropertyChanged exposes the PropertyChanged event.  WPF must just subscribe to PropertyChanged and be on its merry way, right?  I’m sure the WPF dev team wished it were that easy, as we all did, when we realized that the C# event model is a recipe for memory leaks.  Whenever you subscribe to an event, you must unsubscribe from that event or else the subscriber runs the risk of leaking.  For more information, and an excellent write up of this problem and solutions see this article on code project:  Weak Events in C#.  I used one of the solutions here for CLINQ, but I’ll get to that in a minute.

To avoid event based memory leaks, the WPF team came up with the WeakEventManager pattern.  For listening to PropertyChanged events, they specifically implemented the PropertyChangedEventManager.  Any system that must manage subscriptions is basically a smart cache, and two level lookup table.  A subscriber wishes to listen to for a specific property change on a specific object.  For example, imagine a TextBlock that is bound to the Age property on an object of type Person.  The manager first needs to keep a lookup table keyed off the monitored object to another table that is keyed off the name of the property.  You can think of it like this:

Dictionary<INotifyPropertyChanged, Dictionary<string, List<IWeakEventListener>>>

This is all well and good but it leads to the requirements of PropertyChangedEventManager, where each listener must implement the IWeakEventManager interface, which is awesome.  (By awesome, I mean not.  Why should your objects be concerned with such things?)

Now that we have this cache which stores each entry as a WeakReference, we need to somehow clean up this cache as objects get garbage collected.  This is where things start sucking.  For CLINQ we could be monitoring thousands of property changes per second, and if the event management system cleans up too often, then perf goes down the drain.  When I loaded our app in a profiler, I noticed that 30% of our CPU time was being spent in the PropertyChangedEventManager’s cleanup code.  It appears that subscribing or unsubscribing from any single object causes them to “schedule” a clean up.  This means PropertyChangedEventManger does a BeginInvoke on the UI thread that walks the whole cache looking for dead WeakReferences.  For WPF alone it appears to do the job okay, but as CLINQ’s bread and butter is to listen to specific property changes on specific objects that are being added and removed from collections constantly, PropertyChangedEventManager chokes and dies.

Before I describe the replacement, I have two people to thank: Daniel Grunwald on the aforementioned Code Project article on weak events, and the author of the WeakDictionary, Nick Guerrera.

The replacement is called WeakPropertyChangedEventManager, and handles things quite a bit differently.  First, there is still a cache:

WeakDictionary<INotifyPropertyChanged, WeakEventBridge>

This keeps track of what objects are being monitored for property changes.  Each object has one WeakEventBridge which is a tiny wrapper that does two things.  First, it follows the Reusable Wrapper approach from Grunwald, in that WeakEventBridge could technically leak.  This only happens the property changed event never fires again and the listeners have not unsubscribed.  Lame?  Not really.  PropertyChanged fires all the time, and if a listener has been garbage collected the WeakEventBridge will clean up its subscriptions very quickly. Also, the listeners still can still explicitly unsubscribe which is what CLINQ does most of the time anyway.   Granted, if you have one object in the system with a million subscriptions combined with not explicitly unsubscribing listeners and that monitored object’s properties never change, you got a big leak.  Why one would have this many objects monitor property changes on something that never changes is probably a bad idea anyway…  Regardless, there is only ever one instance of the WeakEventWrapper per object in the entire system, which from a footprint perspective is tiny.  Hopefully, you’re not lost at this point, but fear not as here comes the API:

                    (me, sender, args) => me.OnPropertyChanged(sender, args));

First, ignore the hard coded string for the property name in the example as this is bad form. (CLINQ analyzes a lambda expressions to extract property names.)  This call says:  listen for changes to person.Age, and call this.OnPropertyChanged just like normal events in C#.  The reason for the lambda is to prevent any type of closure from being created as this would lead to a strong reference back to “this.”  When person.Age changes the lambda will be called and get this passed in as the me parameter.  Yes, it is a bit weird, but I got this trick from Grunwald’s work and it’s seriously slick.

To unregister:

WeakPropertyChangedEventManager.Unregister(person, "Age", this);

If you always call these two methods then you are good to go. However, what would be the point of going to all this trouble then?  There’s a method for cleaning up dangling weak references just like the original PropertyChangedEventManager:


I have wrestled with whether or not to put in a scheduled cleanup task like the original but with way less frequency. However, considering the low overhead of these “leaks,” I’m going to leave it to the clients to call when they feel it is necessary.  When the 4.0 version of the CLR comes out, I hear it will be able to notify when the garbage collector is making a pass, which would be a perfect time to make this call.  Otherwise, I may add a dirty timer  with configurable interval and thread priority.  Regardless, the overhead of dealing with property change monitoring has been drastically reduced by using this class.  If you would like to check it out, grab Continuous LINQ and pull up a chair to the ContinuousLinq.WeakEvents namespace.

If you found this article useful or lacking, please leave a comment so I can better target and improve my posts.