Reference Counting in Managed Code

Today, while coding Galactic Wars v2.0, I stumbled upon a problem I have been having with content since I started working with XNA. The following diagram shows how easy it is to create the problem and how devastating it can be to any application. In my case, I have two (or more) menus that are referencing a piece of content.

Multiple References

Each menu references the same managed object which is really a wrapper for a second managed object (Texture2D in this case). The second object is a managed wrapper for the underlying unmanaged data, again in this case it is texture data. The problem is when one menu is being phased out (unloaded) and another is being phased in (loaded). The menu being loaded grabs a reference to the content before the other menu can unload it. The ordering is done this way to ensure that a menu actually loads its content before the current menu is unloaded.

After the menu is done loading content, the second menu is unloaded which drops the content and releases the unmanaged memory. Aha! The problem stems from the last point: I am trying to manage unmanaged memory when I should just let the GC take care of it. The reason I do this is for performance reasons, primarily on the Zune. Instead of letting textures just sit around, I release them when they are no longer needed to avoid piling up the garbage.

So what is the solution?

  1. Dereference the Managed Object

    I would love to do this but unfortunately it introduces a second problem. If every menu (object using the content) dereferences the asset, it still will not be collected by the GC. The AssetManager still holds a reference which is now being unused and thus memory is wasted. The upside to this is that I do not need to implement the second option…

  2. Reference Counting!

    By implementing a counter on the asset itself and asking developers to always call Unload or Unload(ILoadable) on the AssetManager, I can guarantee that no Asset will be disposed while another object is using it. The downside is that it is an ugly implementation of something that is done in the GC anyways. The major upside is that even if developers use the previous method, the GC will still eventually catch the wasted memory.

So now Thrust’s AssetManager and IAsset require (and implement) reference counting to avoid the problem described above. And it works wonderfully.

My Introduction to PowerShell

Wow! I can’t believe I have been missing this for so long. It is the answer to all my command line woes in Windows. I have only touched the surface but love it already. Today I created my profile to change the prompt and add a command for copying my FGF binaries to my current working directories:

# Profile PowerShell Script
# Author: John Sedlak
# Site: http://focusedgames.com

$a = (Get-Host).UI.RawUI
$a.ForegroundColor = "White"
$a.WindowTitle = "WPS - Focused Games"

# This function changes the prompt.
function prompt{
	$path = get-location
	$b = Get-Date -format "HH:mm"
	return "$b $path ?> "
}

# This function copies a bunch of FGF libraries to current working directories.
function fgfCopy{
	# These are the platforms that need to be copied
	$platforms = "x86","Zune","Xbox 360"

	# An array of the destinations for copying
	$destinations = "E:\Users\John Sedlak\Code\Games\GW3\trunk\Libraries\"

	# The source directory and the suffix.
	$source = "E:\Users\John Sedlak\Code\FGF\trunk\Bin\"
	$sourceSuffix = "\Release"

	# Loop through all the destinations and all the platforms
	# For each platform, copy some files.
	foreach($destination in $destinations){
		write-host "Starting copy to"$destination
		foreach($platform in $platforms){
			# Build up the source and destination paths
			$tempSource = $source + $platform + $sourceSuffix
			$tempDestination = $destination + $platform

			# Get a list of all DLL files that contain the word Thrust
			$files = get-childItem $tempSource -force | ? {$_.extension -eq ".dll"}|where {$_.name -match "Thrust"}

			# For each file, copy it!
			foreach($dll in $files){
				copy-item $tempSource\$dll $tempDestination
				write-host "Copied"$platform\$dll
			}
		}
	}
}
PowerShell - fgfCopy Command

Provider Model is Win

The provider model’s goal is to allow for the abstraction of implementation to the nth degree by allowing for the choice between separate implementations of the same functionality. This design pattern is incredibly common in Microsoft’s ASP.NET, especially in the realm of security. Developers can choose between different providers for membership, roles and authentication for a single site. The point is that the core functionality of the site does not change, only the implementation. Below is a quick snapshot of how such a model is used in Vodka.

The driving force behind the provider model is the abstraction of the implementation. This is done via an interface.

public interface IAuthenticationProvider{
	bool Authenticate(string username, string password);
}

What gives the provider model its meat and bones is the different implementations of the above interface. The two implementations below represent two authentication backends: an ActiveDirectory installation and an Sql database. Although the meat has been stripped from these two classes, it is clear that their implementations would differ enough to have the two separate classes. Continue reading

Advanced State System: Queues and Removal

During the last part of this little article series I mentioned how I used a queue in each state object to allow for continuous transitioning to occur. The reason for this is to allow for complex transitioning to occur. One example for this is a logo screen where it needs to fade in, stay on screen and then fade out again. Rather than relying on managing the states manually, we can add states on to a queue so they occur automatically.

Continue reading

Advanced State System: Concept and Base

There comes a time when simple state management just will not cut it anymore. I found this out while building up the code base for Thrust’s GUI library. As the objects on the screen became more complex, so did their states. This article covers a new way of thinking about an object’s state, a design that has been proven in Thrust (v1.x). The goals of this state system include the following:

Continue reading