Develop Reference

How do I fire an event handler in a separate thread?

I've created a service which will fire an event for each of the item in the list.
I've used a foreach loop to iterate through the list and trigger the event for each of the item in the list.
In order to improve the performance of the service,
It was suggested that i try to run the event handler in a separate thread.
I'm new to the concept of threading,
Can I get some suggestions on how I can run only the event handler on a separate thread? Should I create a separate thread for the each of the item in my list?
Any suggestions are welcome.
Here is my code:
public void UpdateMessages(){
foreach(var message in messages)
{
message.Received +=
TextMessage_MessageReceived;
}
}
private void RawMessage_MessageReceived(object sender, MessageEventArgs<TextMessage> e)
{
var msgText = sender as RealtimeTextMessage;
RawMessageList[msgText].SetMessageBytes(msgText);
}
In the code snippet I have the event handler RawMessage_MessageReceived which will perform the operation of extracting the bytes from the raw message.
I need to perform the event handling in a different thread since from what I understand about threading, a single thread will be responsible for raising the event for each message and simultaneously will be responsible for event handling of each event.
How can I write a separate thread to take care of the event handling part?

How to await an event handler invocation?

Basically, I have a method which invokes an event handler. the event handler calls an async method and I need to know the results of that method (true or false). since event handlers can only return void, I created my own EventArgs with a success property which I set to true in that method if it goes right.
public virtual async Task<bool> TrySomething()
{
var args = new MyEventArgs();
SomeEvent?.Invoke(this, args);
return args.Success;
}
SomeEvent is hooked up to SomeEventHandler
private async void SomeEventHandler(object sender, MyEventArgs e)
{
e.Success = await AnAsyncMethod();
}
private asyc Task<bool> AnAsyncMethod()
{
//...
}
What I'm confused by is that, is there any guarantee that the method TrySomething will wait for the SomeEvent to finish so Success has been set, before returning it? And if not, how can I ensure that it does?

is there any guarantee that the method TrySomething will wait for the SomeEvent to finish so Success has been set, before returning it?
No. async void means "don't notify the caller when I finish". So the code raising your event cannot know when the event handler has completed, unless you write that additional logic yourself.
And if not, how can I ensure that it does?
Well, that's more of a tricky question. .NET events are designed as what I call "notification events" - that is, when an event fires, it notifies all its listeners. There's no need for "waiting" because there's no way for a listener to provide feedback to the notifier.
Your code is an example of what I call a "command event" - code that is an event but doesn't match the semantics of a notification event. Your code wants a response from the handler.
So, the first question you need to ask yourself is "do I really want this to be an event?" One good litmus test for this is "can I define meaningful semantics if there are multiple handlers?"
More specifically, how should your code behave if multiple handlers are hooked up to the event? Perhaps the answer is "that wouldn't make sense". Or perhaps the answer is "I want to wait for all of them to complete and only be 'successful' if all of them are 'successful'". Or "wait for all and be 'successful' if any of them are 'successful'". Or "wait for the first one to complete and use that result". Or "wait for them to complete one at a time, stopping on the first success". Or "wait for them to complete one at a time, stopping on the first failure". These are the choices that come immediately to mind; there could be more.
If the answer is "that's not going to happen in my code" or "more than one handler doesn't make sense" or "that's too hard of a decision to make right now", then the appropriate answer is to remove the event. It's not an event. It's a method call. In Design Pattern terminology, events are used to implement the Observer Pattern, but what you have is a Strategy Pattern, and that's why events are a poor fit. In this case, you could use Gabriel's answer or something similar where you define the Strategy using an interface, and instead of raising an event you would invoke a method on that interface.
However, if it does make sense to have multiple handlers, and there is a meaningful semantic you can use, then you'll need to modify the EventArgs type to have some sort of "collector" of responses, and then have your event-raising code interpret those responses. The exact code would vary based on the semantics you need.

The whole reason async void is allowed is for event handlers. From the documentation on Async Return Types:
You use the void return type in asynchronous event handlers, which require a void return type.
That said, events are designed to "signal the occurrence of an action" to any interested party, if any (and there can be none, or multiple). Think of it like sending an email notification to whomever subscribed to a specific mailing list: those people might have to do something when they receive the notification, but it's not your concern - you move on to your next task after sending the email. That's all events are. An event handler should not be something that is important for the proper functioning of the object.
Events are not designed to be a "hey this happened, what should I do next?" So there should be no need to await an event handler.
If returning args.Success depends on SomeEventHandler completing successfully, then it shouldn't be an event handler. Instead, you can have a Func<Task<bool>> property (a function that returns Task<bool>). Something like this:
public class SomeClass {
private Func<Task<bool>> IsSuccessful;
public SomeClass(Func<Task<bool>> isSuccessful) {
// Accept a reference to a function and store it
IsSuccessful = isSuccessful;
}
public async Task<bool> DoSomething() {
// Call our function and return the result
return await IsSuccessful();
}
}
Then you could use it like this:
// This is the method we want it to call
private async Task<bool> AnAsyncMethod() {
await Task.Delay(1);
return true;
}
// so we pass it in the constructor of the class.
// You don't have to pass it in the constructor - this is just an example
var myClass = new SomeClass(AnAsyncMethod);
In that way, it's very clear that SomeClass cannot function properly without calling that method and therefore exactly one implementation of that method must be passed into the class.

You could declare the Success property as Task<bool> instead of bool. Then assign it inside the handler like this:
private void SomeEventHandler(object sender, MyEventArgs e)
{
e.Success = AnAsyncMethod(); // Without await
}
At the end you would be able to get the result after invoking the event and awaiting the property.
public virtual async Task<bool> TrySomething()
{
var args = new MyEventArgs();
SomeEvent?.Invoke(this, args);
return await (args.Success ?? Task.FromResult(false));
}

Async event handlers with stateful event args

Sometimes we want the event publisher's actions post firing to depend on some state set by the event handlers. A common example is an event that takes CancelEventArgs. The event publisher takes action after firing, conditioned on the value of the Cancel property. If the handler is long running, we don't want to block the UI thread (users can be doing other things while they are waiting). But async handlers may return before the state is set, and the publisher will not have the correct value when it needs it. I solved this by simply providing a mutable Task property in the event argument. It's the responsibility of the handler to set its value, and the publisher to await on it after firing. This seems to work fine.
One objection might be that stateful event args are arguably bad practice, unless you assume only one handler. You could use higher-order functions instead of events, and that would handle the objection above by enforcing one "handler".
One thing that I'm not sure about is how async/await deals with multiple awaiters.
Are there any guarantees about in what order the continuations are executed?
Is there going to be a race condition where the rest of the firing might execute before the rest of the event handler?
Answer is yes. This feels like it's going be an issue for nested async methods generally, whenever the caller and callee both have actions after the await.
Is there anything about the way I'm doing it that has any drawbacks I haven't mentioned?
Is there some other well-known or well-accepted best practice for accomplishing the objective that I'm unaware of?
Any ideas about how to deal with the race condition?
Thanks!
class Publisher
{
void RaiseMyEvent()
{
var e = new MyEventArgs();
OnRaiseMyEvent(e);
if (e.Task != null) await e.HandlerTask;
if (e.Cancel)
{
// Do one thing
}
else
{
// Do the other
}
}
}
class Subscriber
{
void MyEventHandler(object sender, CancelEventArgs e)
{
// Notify user to wait on process
e.Task = SomeAsyncMethod();
await e.Task;
e.Cancel = GetOutcome();
// Clear any notification
}
bool GetOutcome() { }
}
Actually we can avoid a race by ensuring that any needed state values in the event args needed by the firing method are set prior to the continuation in the handler:
class Subscriber
{
void MyEventHandler(object sender, CancelEventArgs e)
{
// Notify user to wait on process
e.Task = Task.Run(() =>
{
//Do stuff
e.Cancel = GetOutcome();
}
await e.Task;
// Clear any notification
}
bool GetOutcome() { }
}
Both continuations execute on the UI thread, but we don't care about the order.

Sometimes we want the event publisher's actions post firing to depend on some state set by the event handlers.
I call these "command events", as opposed to "notification events", and cover a few approaches to async command events on my blog.
After quite a bit of experience, I have come to the conclusion that command events are an anti-pattern. Events in .NET are designed as notification events, and making them behave differently is awkward at best. To use the GoF terminology, .NET events are used to implement the Observer design pattern, but these "command events" are actually an implementation of the Template Method design pattern.
Consider this quote about the Template Method design pattern (pg 328):
It's important for template methods to specify which operations are hooks (may be overridden) and which are abstract operations (must be overridden)
That's a good identifying quality of command events! And if you find yourself writing a .NET event that either requires a handler or can't have more than one handler, then it's a good indication that .NET events are probably the wrong solution.
If you have a Template Method situation, then usually some form of this will suffice as a solution:
interface IDetails { Task ProcessAsync(); }
class Subject
{
private IDetails _details { get; }
public Subject(IDetails details) { _details = details; }
async Task SomeMethodAsync()
{
...
if (_details)
await _details.ProcessAsync();
}
}

Are c# events handled serially or in parallel?

For example, I have a class that fires an event, and 1000 subscribers to that event. Is a single thread used to fire each subscriber delegate one-by-one? Or does .Net use a thread pool to process some or all of the subscriptions in parallel?

As Tigran said, event invocation is serial. Even more if one of the subscribers throws an exception at some point the rest of them will not be triggered.
The easiest way to trigger an event in parallel will be
public event Action Event;
public void Trigger()
{
if (Event != null)
{
var delegates = Event.GetInvocationList();
Parallel.ForEach(delegates, d => d.DynamicInvoke());
}
}
This implementation will suffer from same problem in case of an exception.

As is, event are simple serial invocation. If you want you can run it in async way, but this is an implementation detail.
In short: there is no any built-in parallelization or async of standard .NET events, it's up to you to implement it.

How to raise an event in C# - Best Approach

I am writing a Windows Form application. It has a thread to perform some operation and when the operation found something it has to notify the main form to change a control.
Currently the notification uses the C# event hadling described in the following MSDN page:
http://msdn.microsoft.com/en-us/library/wkzf914z(VS.71).aspx
But I am not sure about the delegate. Since in the situation I described above the thread invokes the delegate. Is this a thread safe approach to raise the event?
Is it better to implement Windows Messages (SendMessage) in C# and then implement the message handler in the WindowProc.

Unless you need very fine control over the threading, you can probably use BackgroundWorker instead. It handles all of the cross-thread communication for you. You basically put your background code in its DoWork event handler and then pass data back to the UI thread via its ProgressChanged and RunWorkerCompleted events. The link above has a complete example of how to use it.
But in general, simply adding event handlers and raising events is thread-safe as long as you follow some basic guidelines. However, the event handler will be called on the same thread as the code that raises the event. The event handling code may not be expecting to be called on a background thread so that's where BackgroundWorker comes in handy.
The following is a very basic skeleton of a class that raises an event in a thread-safe way. Whether the code that handles the event is thread-safe is another matter entirely.
class MyClass {
public event EventHandler SomethingHappened;
protected virtual void OnSomethingHappened(EventArgs e) {
EventHandler handler = SomethingHappened;
if (handler != null) {
handler(this, e);
}
}
public void DoSomething() {
OnSomethingHappened(EventArgs.Empty);
}
}

Try to use InvokeRequired / Invoke on UI controls. It's better to avoid raw windows message queuing.

The delegate approach isn't all that bad, but the problem is that the event invokes the event handlers in the other thread. That foxes your UI update, which needs to be done in the main thread. So you can use InvokeRequired appropriately in the event handler.
void OnStatusMessage(string s)
{
// might be coming from a different thread
if (txtStatus.InvokeRequired)
{
this.BeginInvoke(new MethodInvoker(delegate()
{
OnStatusMessage(s);
}));
}
else
{
StatusBox.Text += s + "\r\n";
StatusBox.SelectionStart = txtStatus.TextLength;
StatusBox.ScrollToCaret();
}
}
This may not be required when using BackgroundWorker as Josh mentioned. But it's useful if you're considering ThreadPool and WaitCallBack(*) to manage threads.
An issue with using Windows messages is that you have to know which window to send messages to, and multiple subscribers is more painful. (For events you just have to += another handler)
I amn't able to post a hyperlink for WaitCallBack because I don't have multi-link pedigree yet.