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();
}
}
Related
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));
}
I am developing a WinForms Application.
I created a custom Control (inheriting from Control class). It has its own Eventhandlers to allow the forms to observe some events.
public event EventHandler<TextBoxFilterEventArgs> DataGetFiltered;
My issues came when, inside the control,in some specific situations I perform a call to the registered receivers:
this.Enabled=false;
if (DataGetFiltered != null)
DataGetFiltered(this, new TextBoxFilterEventArgs(itemsFiltered));
this.Enabled=true;
You can see I set the control disabled/enabled before and after the call.
The form containing the control is registering some methods to that event in a async way:
txtFilter.DataGetFiltered += async (s, e) => await txtFilterByDesc_DataGetFiltered(s, e);
private async Task txtFilterByDesc_DataGetFiltered(object sender, TextBoxFilterEventArgs e)
{
await Task.Run(()=>/*some code*/);
}
What happens?
The control calls to the events handlers registered but it continues to run this.Enabled=true;without waiting previous call to finish( but it has been awaited!)
What's going on?
What happens?
After disabling control, your event handling code runs asynchronous delegate.
The delegate ultimately calls Task.Run and offloads some work to a thread pool thread.
Then delegate returns, and control becomes enabled again, but scheduled task still runs in background.
The control is a textbox that i want to get enabled/disabled during the handling of eventhandlers. I have to move that logic to the handler itself?
Short answer: yes.
More detailed answer: while you're using standard .NET event handling pattern, you have to move this logic into event handler. Event doesn't know about handlers implementation. They can be either synchronous, or asynchronous. So, all you can do is to let event handler to manage Enabled property.
Technically, you can invent some sort of asynchronous event handler, but, actually, you shouldn't. .NET developers know, that event delegate is of type EventHandler/EventHandler<T>. Custom event delegate type breaks well-known pattern.
I think it's because your event handler uses await, but your called method doesn't wait for the handler! So, you need to create your own event that returns Task, like the following:
public delegate Task DataGetFiltered(object sender, TextBoxFilterEventArgs e);
public event DataGetFiltered OnDataGetFiltered;
And in the called method:
if (null != this.OnDataGetFiltered)
{
var args = new TextBoxFilterEventArgs(itemsFiltered);
foreach (var handler in this.OnDataGetFiltered.GetInvocationList().Cast<DataGetFiltered>())
{
await handler(this, args);
}
}
Let's say I need to implement a C# class library that executes a long-running calculation. When some of the values calculated inside the calculation cross a certain threshold, I have to notify the user, nothing more.
In this case, how do I implement events inside a task? Is that even a proper solution? If not, how can I notify the user of things happening inside my task?
Depending on what you desire to have happen when you say "notify the user", there are quite a few options, some more complex than others (e.g. using a messaging library like RabbitMQ).
However, a simple answer to your question would interpret "notify the user" as meaning "notify the caller of my long running process." In that case, you could create an EventHandler in the class that has your async long running process, and simply call that event handler when you want to "notify" your caller.
Code for the class could look like this:
public class LongTask
{
public event EventHandler StillInProgress;
public async Task<bool> LongRunningProcessAsync()
{
await Task.Delay(5000);
OnStillInProgress(new EventArgs());
await Task.Delay(5000);
return true;
}
protected virtual void OnStillInProgress(EventArgs e)
{
StillInProgress?.Invoke(this, e);
}
}
In the code above, the caller of your long running process could also subscribe to your "StillInProgress" event, and get notifications whenever you call it.
Subscribing to event by caller would look something like this:
var longRun = new LongTask();
longRun.StillInProgress += LongRun_StillInProgress;
// Method that will handle the "notification"
private void LongRun_StillInProgress(object sender, EventArgs e)
{
Debug.WriteLine("InProgress");
}
There are other options, but this is perhaps the most straight-forward.
I've read and experimented more with the problem, and seeing that all I need is to run code on the UI thread when certain conditions of the task are met, it's better to go the IProgress route (Peter Bons and Servy's recommendation). Simpler, better and fully supported. The link posted by Peter Bons (authored by Stephen Cleary) is a great writeup on how to do it.
Thanks to everyone for the help.
I have a piece of code that has two event handlers. I want these two event handlers to notify another method that there is some work to be done.
I have implemented this using a ManualResetEvent, but I am unsure if this is the best way to achieve what I want, or if there is some better way.
static ManualResetEvent autoEvent = new ManualResetEvent(false);
void begin() {
ThreadPool.QueueUserWorkItem(new WaitCallback(genericHandler));
}
void OnEvent1(object sender) {
autoEvent.Set();
}
void OnEvent2(object sender) {
autoEvent.Set();
}
void genericHandler(object info) {
while (true) {
autoEvent.WaitOne();
// do some work
}
}
One of the most important questions I have is: After autoEvent.WaitOne(), I do some work and that work consumes time. In the meanwhile, another event is triggered, and Set() is called before the genericHandler gets to WaitOne() again. When WaitOne is reached again, will it wait for another Set(), or proceed if a Set() has been called before reaching the WaitOne()?
Is this the best way to implement multiple publishers and one subscriber pattern in C#? Or should I use another thing instead of the ManualResetEvent?
Note: The genericHandler is in a different thread because Event1 and Event2 have different priorities, so in the handler I check whether Event1 has pending work, before checking Event2.
Your code does indeed do what you think it does, and the race condition you describe is not a problem at all. As per the documentation of a MRE, when it is set it will remain in the "signaled" state until it is reset by a call to WaitOne.
The question and code is presented too vaguely to offer good, specific advice. That said...
No, the use of ManualResetEvent is not appropriate here. Not only does it needlessly complicate the code, your code relies on a long-running thread that you have taken from the thread pool (where only short-lived tasks should be executed).
If you have a need for events to trigger the execution of some asynchronous work, then you should be using the async/await pattern, where each new unit of work is invoked via the Task class.
For example:
async void OnEvent1(object sender) {
var workUnit = ... ; // something here that represents your unit of work
await Task.Run(() => genericHandler(workUnit));
}
void OnEvent2(object sender) {
var workUnit = ... ; // something here that represents your unit of work
await Task.Run(() => genericHandler(workUnit));
}
void genericHandler(object info) {
// do some work using info
}
Note that the event object and the begin() method are eliminated entirely.
It's not clear from your question whether each work unit is entirely independent of each other. If not, then you may also require some synchronization to protect shared data. Again, without a more specific question it's not possible to say what this would be, but most likely you'd either use the lock statement, or one of the Concurrent... collections.
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.