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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With