Detecting that a ThreadPool WorkItem has completed/waiting for completion

Question

For whatever reason, ThreadPool's QueueWorkItem doesn't return an IAsyncResult or some other handle to the work item, which would allow to wait until it's completed. There are RegisterWait... methods, but you have to pass a WaitHandle and creating them is expensive (see IAsyncResult documentation, which advises you to delay creating a WaitHandle until requested). The Task Parallel Library will fix this lack, but there is a long wait before that's available. So, are there any problems with this design:

public class Concurrent<T> {
    private ManualResetEvent _resetEvent;
    private T _result;

    public Concurrent(Func<T> f) {
        ThreadPool.QueueUserWorkItem(_ => {
                                         _result = f();
                                         if (_resetEvent != null)
                                             _resetEvent.Set();
                                     });
    }

    public WaitHandle WaitHandle {
        get {
            if (_resetEvent == null)
                _resetEvent = new ManualResetEvent(_result != null);
            return _resetEvent;
        }

    ...

EDIT: I asked a follow-up question about the concerns which arise when using async delegates instead of the ThreadPool.

Answer 1

Well, you've got a race condition between fetching the WaitHandle and setting it. Do you really want the caller to be waiting forever if they happen to be a tiny bit late?

You should probably do some appropriate locking and keep an "I've finished" flag so that if you do create the WaitHandle after it's finished, you set it before returning it.

I'd also personally write a static factory method rather than just using a public constructor - or make it a "create and then explicitly start" pattern. Queuing the work item in the constructor feels weird to me.

Answer 2

Why aren't you using an asynchronous delegate, as demostrated here:

http://msdn.microsoft.com/en-us/library/h80ttd5f.aspx

That would make Concurrent obsolete, no?