Following on from my BeginInvoke()/EndInvoke() question, are there major differences in performance/anything else between Delegate.BeginInvoke() and using QueueUserWorkItem() to invoke a delegate asynchronously?
The main thing I can think of with QueueUserWorkItem
is that you have to use the WaitCallback
delegate type, which looks tricky if you already have a SomeRandomDelegate
instance and some args. The good news is that you can fix this with a closure:
ThreadPool.QueueUserWorkItem(
delegate { someDelegate(arg1, arg2); }
);
This pattern also ensures you get proper strong typing at compile time (unlike passing an object
state arg to QueueUserWorkItem
and casting it in the target method). This pattern can also be used when calling methods directly:
ThreadPool.QueueUserWorkItem(
delegate { SomeMethod(arg1, arg2); }
);
Obviously, without an EndInvoke
equivalent, you also can't get a return value back out unless you call a method / raise an event / etc at the end of your method... on a related note, you need to be careful with exception handling.
http://blogs.msdn.com/cbrumme/archive/2003/07/14/51495.aspx
says:
"One surprising fact is that this is also why Delegate.BeginInvoke / EndInvoke are so slow compared to equivalent techniques like ThreadPool.QueueUserWorkItem (or UnsafeQueueUserWorkItem if you understand the security implications and want to be really efficient). The codepath for BeginInvoke / EndInvoke quickly turns into the common Message processing code of the general remoting pathway."
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