Question

The following code demonstrates my dilemma. The code creates a background thread which processes something, then Invokes the UI thread with the result.

It may throw an exception if the background thread calls Invoke on the form after the form has closed. It checks IsHandleCreated before calling Invoke, but the form might close after the check.

void MyMethod()
{
    // Define background thread
    Action action = new Action(
        () =>
        {
            // Process something
            var data = BackgroundProcess();

            // Try to ensure the form still exists and hope
            // that doesn't change before Invoke is called
            if (!IsHandleCreated)
                return;

            // Send data to UI thread for processing
            Invoke(new MethodInvoker(
                () =>
                {
                    UpdateUI(data);
                }));
        });

    // Queue background thread for execution
    action.BeginInvoke();
}

One solution might be to synchronize FormClosing and every call to Invoke, but that doesn’t sound very elegant. Is there an easier way?

Answer 1

Yes, there’s a race here. A takes a good millisecond before the target starts running. It will work ‘better’ if you use Control.BeginInvoke() instead, the form’s Dispose() implementation will empty the dispatch queue. But that’s still a race, albeit that it will strike very rarely. Your code as written in the snippet doesn’t require Invoke().

The only clean fix is to interlock the FormClosing event and to delay the close until you got confirmation that the background thread is completed and can’t be started again. Not easy to do with your code as is since that requires a ‘completed’ callback so you can really get the form closed. BackgroundWorker would be a better mousetrap. The Q&D fix is to catch the ObjectDisposedException that BeginInvoke will raise. Given how rare this will be when you use BeginInvoke(), that ugly hack could be acceptable. You just can’t test it 🙂