How about multicast events?

P. Kim — Thu, 12 Aug 2004 14:41:00 GMT

Thank you for the excellent article; this is one of the cleanest design patterns for asynchronous tasks that I have encountered. However, is it not the case that the Target property of the event returns only the target of the last instance method on the event's invocation list? If there are multiple threads subscribed to the event, therefore, it is not guaranteed that the event will be fired in a thread-safe manner for all clients, and responsibility for thread safety again devolves to the user interface.

re: How about multicast events?

David Hill — Thu, 12 Aug 2004 22:15:00 GMT

The Control.Invoke or BeginInvoke methods ensure that the target of the delegate receives the event on the UI thread. If the delegate happens to be a multicast delegate (ie, a delegate chain) then all targets will be called on the UI thread.

It won't matter if the other targets are not Control derived objects. The event will be invoked on the thread of the control on which the Invoke or BeginInvoke method was originally called. In this case, the target will probably not care which thread it is called on because it is not Control derived.

Of course, if you needed more control over whether each event was marshalled to the UI thread or not, you could always use the GetInvocationList method of the delegate and fire each one manually, checking for the target's type and handling exception appropriately, etc. You would also have to do this if you had multiple message loops, each on a different thread with controls created on each thread.

Making a Rich Client Smart : Using Multiple Threads

How about multicast events?

re: How about multicast events?