VCL Threading – Indeterminate Lifetimes

[Estimated Reading Time: 6 minutes]

Sometimes when you launch a thread you don’t know when it will complete whatever processing it is tasked with. Sometimes you do. Sometimes it may never complete and will require that you expressly terminate it. Usually any given thread will have a lifecycle that is at least consistently one or the other, but sometimes you will come across an awkward thread which is not so straightforward.

Sometimes you will be creating a thread on behalf of somebody else who is making these decisions.

Lifecycle Options

With Delphi threads you basically have two options when it comes to thread lifetimes, governed by the FreeOnTerminate property of the thread object.

If set TRUE, then the thread will destroy itself upon termination. If set (or left) FALSE, then it will not, and someone/something will have to free it at some point.

But what if you have a thread which you would like to free itself when it completes, but which you would like to be able to terminate at will, before it completes normally, under some circumstances (or where this decision is beyond your control) ?

If you set FreeOnTerminate to TRUE and the thread you are trying to terminate has already completed then anything you attempt using a reference to that thread is likely to cause an exception since the thread object will have already been Free‘d:

  thread := TMyThread.Create(FALSE);

  // Time passes and things change....

  if someCondition then
    thread.Terminate;

Even calling thread.WaitFor or testing if thread.Terminated could blow up in our face if the thread has already terminated (and has thus already Free‘d itself).

What to do ?

This was part of the same exercise that involved the use of Windows message based thread synchronisation – the threading is an entirely private implementation detail, so I had the additional problem of how to expose those parts of the thread that were appropriate whilst keeping the rest secure. i.e. a more accurate representation of the situation was:

  thread := SomeFunctionWhichCreatesAThreadIMightTerminate(..);

  // Time passes and things change....

  if someCondition then
    thread.Terminate;

By returning a reference to the thread itself, as well as the Terminate method, the consumer of my function has direct access to the thread and can do whatever they wanted with it, which is simply not appropriate.

I realised that I could avoid the problem with a bit of additional indirection.

Sneaking Up On The Problem

Instead of returning a reference to the worker thread itself I would return a reference to a lightweight container which held the thread reference and exposed only that functionality which I wished to provide to any potential consumers:

  TThreadContainer = class
  private
    fThread: TMyThread;
  public
    procedure Terminate;
  end;

  procedure TThreadContainer.Terminate;
  begin
    fThread.Terminate;
  end;

This keeps the consumer at arms length from the thread but does not solve the problem of the situation where the container is potentially used to Terminate the thread after it has in fact already terminated and Free‘d itself.

But it does make a solution possible, via a simple change to the TMyThread class itself.

The function that created the worker thread would first create the required container. A reference to the container is then provided to the thread constructor which keeps a reference to it as well as setting the container.fThread member to self.

The thread class then also implements a destructor and NIL‘s the container.fThread.

   constructor TMyThread.Create(...; aContainer: TThreadContainer);
   begin
     fContainer := aContainer;
     fContainer.fThread := self;

     ...

     FreeOnTerminate := TRUE;

     inherited Create(FALSE);
   end;

   destructor TMyThread.Destroy;
   begin
     fContainer.fThread := NIL;

     inherited Destroy;
   end;

Now, in the Terminate method of the container, I can first check that the thread reference is still assigned. If it is, then the thread may still be safely terminated. If it is not, then the thread has already terminated and the container Terminate method need do nothing.

However, in solving this problem a new one is created.

A potential race condition has been introduced since the thread could terminate (and free) in the interval between testing the assignment of the fThread reference and calling Terminate upon it.

This is possible because of an often overlooked aspect of using FreeOnTerminate threads: The thread object is destroyed as the last act of the thread itself. i.e. the thread class destructor is executed by the worker thread, not by the VCL thread.

The potential problem here is a far less likely occurrence than the thread terminating before being expressly terminated, but it is a potential problem and one that would be incredibly difficult to track down were it ever to occur.

A similar problem does not arise in the constructor because that is called in the context of the thread creating the new thread instance.

Race to the Finish

A critical section on the container solves this race condition situation (created and destroyed by the container itself – trivial details not shown).

  procedure TThreadContainer.Terminate;
  begin
    fCS.Enter;
    try
      if Assigned(fThread) then
        fThread.Terminate;

    finally
      fCS.Leave;
    end;
  end;

  destructor TMyThread.Destroy;
  begin
    fContainer.fCS.Enter;
    try
      fContainer.fThread := NIL;

    finally
      fContainer.fCS.Leave;
    end;

    inherited Destroy;
  end;

Another problem solved. But there is another one: Who cleans up the container ?

The thread cannot Free it otherwise we simply re-introduce the original problem.

The consumer (holding the reference returned from the function) cannot free it either, since if it does so without terminating a still running thread the thread will throw an exception when it is destroyed.

In my particular case, the consumer may not even be concerned with terminating the thread state at all. They may not even be holding on to a reference to the container in the first place !

One further change plugs this gap: Implement the container as a class with a reference counted lifetime. An interfaced class.

Once More Into the Breach

Using an interface is even better since it means I need only expose the interface implemented by the container, further hiding the implementation details that should not concern the consumer !

Note: If you are asking yourself “Why not implement the interface and use reference counted lifetime management on the thread itself ?” you should remember that if the thread runs to the end of it’s natural life then we want it to Free itself, which will cause problems when any interface references are later Release‘d. i.e. we’re back to the very first problem all over again.

The container is where the interface will be implemented, and the interface is very simple:

  type
    IThreadContainer = interface
    ['{FE327C1C-7A6F-4A9C-8FB1-B3C1845E5CAD}']
      procedure Terminate;
    end;

The change to the container class to a reference counted, interfaced object declaring support for this interface is similarly straightforward:

    TThreadContainer = class(TCOMInterfacedObject, IThreadContainer)
      ...

Note: TCOMInterfacedObject is my own version of TInterfacedObject which contains bug fixes over the VCL TInterfacedObject and makes the COM reference counted lifetime explicit in the name. There is a companion class which supports interfaces without reference counted lifetime..

The only minor complication is in addressing the potential situation where the consumer of my function chooses not to hold on to the container interface. In that situation there will be no references maintained to the container and it will most likely be Release‘d and thus Free‘d before the thread itself terminates, causing problems in the thread destructor.

To prevent this, as well as holding on to a reference to the container object using an object reference, the thread must retain a reference to the container interface in addition to the object reference (to access the members not exposed through the interface) and release that reference only when destroyed.

  TMyThread = class(TThread)
  private
    fContainerRef: IThreadContainer;
    fContainer: TThreadContainer;
    ...
  end;
 

  constructor TMyThread.Create(...; aContainer: TThreadContainer);
  begin
    fContainerRef := aContainer;
    fContainer := aContainer;
    fContainer.fThread := self;
    ...
  end;
    

  destructor TMyThread.Destroy;
  begin
    fContainer.CS.Enter;
    try
      fContainer.Thread := NIL;
      fContainerRef     := NIL;

    finally
      fContainer.CS.Leave;
    end;

    inherited;
  end;

If you’ve had your morning coffee you should be jumping up and down right about now, pointing at the screen and yelling at me about a glaring mistake.

Determined to Find a Solution

As written above, if the thread is holding on to the only reference to the container then at the point at which the destructor attempts to leave the critical section both that critical section and the container will have been destroyed, thanks to the deterministic nature of reference counted lifetime management.

Fortunately, that same determinism provides us with a simple solution.

Before entering the critical section the destructor need only to take an additional reference to the container, which it will release only after leaving the critical section. This reference can be a simple IUnknown (or IInterface if you prefer) since we won’t be using it to do anything, other than maintaining that additional reference:

  destructor TMyThread.Destroy;
  var
    localRef: IUnknown;
  begin
    localRef := fContainer;
    fContainer.CS.Enter;
    try
      fContainer.Thread := NIL;
      fContainerRef     := NIL;

    finally
      fContainer.CS.Leave;
      localRef := NIL;
    end;

    inherited;
  end;

I explicitly NIL rather than leaving the reference to drop out of scope only to make the intended use clear but also to counter any (perhaps remote) possibility that the compiler will optimise the otherwise unused localRef variable out of existence.

Note: These life-preserving additional references could be achieved without the use of additional member or local variables by using explicit calls to _AddRef and _Release at the appropriate points instead.

Bringing It All Together

In a coming-soon post it will become clear why I’ve been working on thread synchronization and thread lifetime issues. Although it is a VCL based Delphi project it is actually connected with my interest in Android development with Oxygene.

All will become clear.

Eventually. 🙂