Object Pooling, Part 2

This is the second article in my mini series about object pooling. You can find the first part here. Now I want to get going by defining an interface for the pool – I don’t mean a C# interface, but rather a framework for the methods and properties that the implemented class is going to have. I’ve also given some thought to the internal organization. One thing’s clear: the pool needs to have a list of objects that it currently holds. This list will have to be extendable, but there aren’t any other requirements, so a simple List<T> should do just fine. A more interesting question is, what exactly does the list store? It could just be instances of the object type we are pooling, but isn’t there management information that has to be stored as well? Like which objects are in use and which aren’t, to start with?

The Slot

So, my decision is that the list will store instances of another type we need, which is what I call a Slot. A Slot is an encapsulation of the actual type of the pooled object, which adds all the internal per-object management information that the pool needs to do its work. For now, there’s just the object itself and a flag that says whether the object is currently in use or not. I have decided to make the Slot class a nested class, inside the Pool class. The Slot is really just a management detail of the Pool, this is completely irrelevant to the user of the Pool. It also allows the Slot to share the type parameter with the Pool. Here’s the code for the Pool and the Slot classes. I have added documentation comments, so it should be self-explanatory.

/// <summary>
/// This is the main Pool class, which implements object pooling.
/// </summary>
public sealed class Pool<T> {
  /// <summary>
  /// The slot class represents an entry in the pool's list. It holds information about
  /// the actual pooled object, plus per-object management information.
  /// <summary>
  sealed class Slot {
    T poolObject;
    /// <summary>
    /// Returns the pooled object itself.
    /// </summary>
    public T PoolObject {
      get {
        return poolObject;
      }
    }

    bool inUse;
    /// <summary>
    /// Returns a value indicating whether this slot is currently in use or not, in other words
    /// whether its object has been reserved for use at this time.
    /// </summary>
    public bool InUse {
      get {
        return inUse;
      }
    }
  }

  List<Slot> pool;

  /// <summary>
  /// Returns a pooled object. After use, the pooled object must be returned to the
  /// pool by calling the ReleaseObject method.
  /// </summary>
  public T GetObject( ) {
  }

  /// Releases an object that was previously fetched from the pool
  /// by a call to the GetObject method.
  ///
  public void ReleaseObject(T poolObject) {
  }
}

The source code

A word about the code I’m showing here: This article series is supposed to be about the design process of the whole pooling system. So I’m planning to show parts of the source code in the articles, such as I do here. The parts shown in each article won’t be useful to run on their own, of course – I assume the whole thing will soon be much too long to be posted in a blog post in its entirety. When the sample project comes to the point where it makes sense, I will provide a download with a sample program and the complete classes.

Sorry, this blog does not support comments.

I used various blog hosting services since this blog was established in 2005, but unfortunately they turned out to be unreliable in the long term and comment threads were lost in unavoidable transitions. At this time I don't want to enable third-party services for comments since it has become obvious in recent years that these providers invariably monetize information about their visitors and users.

Please use the links in the page footer to get in touch with me. I'm available for conversations on Keybase, Matrix, Mastodon or Twitter, as well as via email.