Question

Here is the code:

class LongOp
{
    //The delegate
    Action longOpDelegate = LongOp.DoLongOp;
    //The result
    string longOpResult = null;

    //The Main Method
    public string CallLongOp()
    {
        //Call the asynchronous operation
        IAsyncResult result = longOpDelegate.BeginInvoke(Callback, null);

        //Wait for it to complete
        result.AsyncWaitHandle.WaitOne();

        //return result saved in Callback
        return longOpResult;
    }

    //The long operation
    static void DoLongOp()
    {
        Thread.Sleep(5000);
    }

    //The Callback
    void Callback(IAsyncResult result)
    {
        longOpResult = "Completed";
        this.longOpDelegate.EndInvoke(result);
    }
}

Here is the test case:

[TestMethod]
public void TestBeginInvoke()
{
    var longOp = new LongOp();
    var result = longOp.CallLongOp();

    //This can fail
    Assert.IsNotNull(result);
}

If this is run the test case can fail. Why exactly?

There is very little documentation on how delegate.BeginInvoke works. Does anyone have any insights they would like to share?

Update
This is a subtle race-condition that is not well documented in MSDN or elsewhere. The problem, as explained in the accepted answer, is that when the operation completes the Wait Handle is signalled, and then the Callback is executed. The signal releases the waiting main thread and now the Callback execution enters the “race”. Jeffry Richter’s suggested implementation shows what’s happening behind the scenes:

  // If the event exists, set it   
  if (m_AsyncWaitHandle != null) m_AsyncWaitHandle.Set();

  // If a callback method was set, call it  
  if (m_AsyncCallback != null) m_AsyncCallback(this);

For a solution refer to Ben Voigt’s answer. That implementation does not incur the additional overhead of a second wait handle.

Answer 1

The ASyncWaitHandle.WaitOne() is signaled when the asynchronous operation completes. At the same time CallBack() is called.

This means that the the code after WaitOne() is run in the main thread and the CallBack is run in another thread (probably the same that runs DoLongOp()). This results in a race condition where the value of longOpResult essentially is unknown at the time it is returned.

One could have expected that ASyncWaitHandle.WaitOne() would have been signaled when the CallBack was finished, but that is just not how it works 😉

You’ll need another ManualResetEvent to have the main thread wait for the CallBack to set longOpResult.