Should you add and remove event handlers willy-nilly?
-
I have had an email from one of our equipment suppliers complaining that I am using event handlers incorrectly. We have an app that uses MVC and switches in various controllers, forms, etc. As a form is switched in, it is attached to the relevant hardware and GUI events using the += syntax... when the form is switched out, the events are unbound using -=. Now, I thought this was OK to do, but then I had this email from the supplier (modified to protect identities) "You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things. This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application) and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors." Now, I'm pretty sure that adding and removing event handlers is thread safe, and even if it wasn't, I can't see how a 'racetrack' condition could occur. (Also, if the event was raised in the GUI thread, surely it will be handled in the GUI thread?) So, may I ask the panel this question? Is there a Microsoft publication somewhere that details the design philosophy behind the .Net 1.1 event handlers? Thanks in advance! Gizz.
-
I have had an email from one of our equipment suppliers complaining that I am using event handlers incorrectly. We have an app that uses MVC and switches in various controllers, forms, etc. As a form is switched in, it is attached to the relevant hardware and GUI events using the += syntax... when the form is switched out, the events are unbound using -=. Now, I thought this was OK to do, but then I had this email from the supplier (modified to protect identities) "You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things. This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application) and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors." Now, I'm pretty sure that adding and removing event handlers is thread safe, and even if it wasn't, I can't see how a 'racetrack' condition could occur. (Also, if the event was raised in the GUI thread, surely it will be handled in the GUI thread?) So, may I ask the panel this question? Is there a Microsoft publication somewhere that details the design philosophy behind the .Net 1.1 event handlers? Thanks in advance! Gizz.
It's crap what he is telling you. Events have per se nothing to do with threading. When an event is called all bound functions are called within the same thread as the raiser of the event. An event is nothing more than a specialized way to deal with delegate (function pointer) lists. Binding and unbinding is nothing more than adding and removing from this list.
-
It's crap what he is telling you. Events have per se nothing to do with threading. When an event is called all bound functions are called within the same thread as the raiser of the event. An event is nothing more than a specialized way to deal with delegate (function pointer) lists. Binding and unbinding is nothing more than adding and removing from this list.
-
I have had an email from one of our equipment suppliers complaining that I am using event handlers incorrectly. We have an app that uses MVC and switches in various controllers, forms, etc. As a form is switched in, it is attached to the relevant hardware and GUI events using the += syntax... when the form is switched out, the events are unbound using -=. Now, I thought this was OK to do, but then I had this email from the supplier (modified to protect identities) "You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things. This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application) and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors." Now, I'm pretty sure that adding and removing event handlers is thread safe, and even if it wasn't, I can't see how a 'racetrack' condition could occur. (Also, if the event was raised in the GUI thread, surely it will be handled in the GUI thread?) So, may I ask the panel this question? Is there a Microsoft publication somewhere that details the design philosophy behind the .Net 1.1 event handlers? Thanks in advance! Gizz.
A race condition can occur when an event is fired incorrectly. It has nothing to do with how handlers are subscribed and unsubscribed. If you fire like this:
public event EventHandler HandleThis;
void OnHandleThis(EventArgs e)
{
if (HandleThis != null)
{
HandleThis(this, e);
}
}A separate thread could unsubscribe the last handler from the HandleThis event between the time you check for null and the time you actually fire it. You can eliminate the race condition by using a temporary variable.
void OnHandleThis(EventArgs e)
{
EventHandler handler = HandleThis;if (handler != null)
{
handler(this, e);
}
}This page[^] mentions the problem and the solution. It's for WinFX, not v1.1, but it's the same concept. I'm not sure why your supplier thinks you should handle events you're not interested in, but he's wrong. Charlie if(!curlies){ return; }
-
This I know! But, is there a useful Microsoft sponsored document that explains this in words of 1 syllable? TIA
Sorry I have no link at hand but when reading such things I just have to rant about it. :mad:
-
I have had an email from one of our equipment suppliers complaining that I am using event handlers incorrectly. We have an app that uses MVC and switches in various controllers, forms, etc. As a form is switched in, it is attached to the relevant hardware and GUI events using the += syntax... when the form is switched out, the events are unbound using -=. Now, I thought this was OK to do, but then I had this email from the supplier (modified to protect identities) "You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things. This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application) and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors." Now, I'm pretty sure that adding and removing event handlers is thread safe, and even if it wasn't, I can't see how a 'racetrack' condition could occur. (Also, if the event was raised in the GUI thread, surely it will be handled in the GUI thread?) So, may I ask the panel this question? Is there a Microsoft publication somewhere that details the design philosophy behind the .Net 1.1 event handlers? Thanks in advance! Gizz.
Gizz quoted his supplier:
You should only ever add/remove an event handler once in most applications. It is not designed by Microsoft to have event handlers added and removed continuously as a method to controlling these things.
Well, I don't know about adding/removing event handlers "continuously," but I see nothing wrong with changing event handlers more than once. I've been exploring flow-based programming lately and have been experimenting with using events/delegates as a means of realizing it. So I have no problem with adding/removing event handlers several times during the lifetime of an application as a means of controlling the flow of a program (or whatever). In fact, I think it's a pretty cool approach.
Gizz continued to quote his supplier:
This is because an event handler is usually dealt with in another thread (or how else could it be generated for the application)
If you're receiving event notifications from another thread, then thread-safety is an issue to be concerned about. but that has nothing to do with this:
and adding/removing notifications to the other thread can easily be the subject of racetrack timing errors.
Adding and removing event handlers to an event is thread safe. When compiling a field-like event, the compiler automatically creates storage to hold the delegate and creates accessors for the event that add or remove event handlers to the delegate field. To be thread-safe, the addition or removal operations are done while holding the lock on the containing object for an instance event or the type object for a static event. The C# Programming Language - 10.7.1 As far as firing an event, see Charlie Williams' reponse. There is a thread safety issue there. -- modified at 15:10 Monday 21st November, 2005