141: Reference Counting. Still In Use!

Can this object be thrown away yet? Keeping track of how many places are still using an object is one way to answer this question. The way it works is like this. When you first create an object it starts out with a reference count of zero. That just means that it’s not being used. You normally want to increase that reference count right away. Some libraries might even do this for you. The point is that if you intend to use and continue referring to some object instance, then you need to either increase the reference count or know for sure that it’s already been increased for you. This shows that the object is being used in a single place in the code. You don’t have to go hunting through the code to find out where it’s being used. You can just ask the object itself what its reference count is. Now, whenever you’re done with the object, instead of deleting it, you instead release it. There’s usually a method on the object called release that you can call. This will cause the reference count to decrement by one. and if the count goes to zero, then the object can delete itself. What happens when things go wrong? And how can things go wrong? What if two objects each refer to the other? In other words, each object has a reference counted data member of the other object and they’ve both added a reference to the other object to show that it’s in use. This situation is called a cyclic dependency. It doesn’t have to be just two objects. Any cycle of at least two object can cause the problem. Maybe object A is holding a reference on object B which is then holding a reference on object C. You get a cyclic dependency if object C also has added a reference on object A. It forms a loop. None of the reference counts can go to zero and the objects are stuck. Listen to the full episode or read the full transcript below to find out how to fix this problem. Transcript In real life, we do this all the time. Usually a bit more informally though. You see a cup on the table and before tossing the drink and washing the cup, it’s a good idea to ask first. “Is anybody still using this cup?” When nobody answers, that’s when you clean the cup. The problem with this approach comes when somebody asks, “Hey, what happened to my cup?” The topic today is actually similar to episode 127 about smart pointers. That’s because smart shared pointers use reference counting to keep track of their usage. For today though, I want to focus just on the reference counting. How does it work and what are some of the downsides and benefits? Most of the uses of reference counting are related to knowing when it’s safe to delete objects. But there’s also another aspect to this and that’s when to free system resources such as file handles, window handles, database connections, etc. There’s also the question about the extent that reference counting should be used. Should it be used for everything or only certain class instances? When you try to use reference counting everywhere, then you end up with something like the Objective-C language. This language recently added a compiler option to turn on automatic reference counting. It’s the same concept and automatic reference counting just means that the compiler inserts code for you to make sure that references are incremented and decremented at the right times. First of all, let me say something about timing. It’s always possible that a different thread or even a different process will start executing just as a reference counted object is about to be reclaimed. This can delay the actual object cleanup for an unknown amount of time. Usually this will be fairly short. But I mention it because deterministic execution of objects going out of scope is usually listed as one of the strengths of reference counting. All you really know is what a single thread will do next. What exactly is reference counting? Whi