Is it a recommended practice to raise all the events asynchronously if...

Question

Is it a recommended practice to raise all the events asynchronously if the class (event raising object) does NOT interested on how the parameters of the events are manipulated by the client objects (receivers of the events)?!

Please guide me?

Answer 1

No it's not a recommended practice.

You have to consider other factors, like:

• Thread affinity requirements of the generting class.
• Whether UI elements are involved (a variation on thread affinity)
• Whether the classes responding to events can accept concurrent processing on multiple threads (aka are they threadsafe).
• Whether there is thread-local data involved (e.g. Thread.CurrentPrincipal, HttpContext, etc)
• Whether you are gaining anything from multi-threaded processing.

Multithreading makes things complicated. Asynchronous event handling requires multithreading. You should only introduce complexity if it buys you something (e.g. improved performance, more responsive user interaction, simplification of something else that would be even more complicated).

Without knowing the details of your specific situation, it's impossible to recommend whether asynchronous eventing is appropriate. But all things being equal - I would avoid asynchronous eventing unless I had a strong reason for it.

Answer 2

No it is not. In fact, raising events asyncrhonously can introduce a host of new issues into your program. You shouldn't do it unless you have a compelling reason.

Answer 3

No, it is not recommended practice. All the usual caveats apply in that you need to ensure that deadlocks and races do not occur.

The short of it is, it would be great if all events could summarily invoked asynchronously, but it is imperative you execise the same caution you would with any multithreaded code base.

Answer 4

I wanted to add a few things in addition to LBushkin's great answer.

The other problem with this approach is that you're going to take an established pattern (events) and essentially without warning to the user change the manner in which in functions. This is a recipe for confusing user and creating bugs in their application.

Yes you can argue that people should be reading the documentation. But really who is going to read the documentation for a standard .Net event to see if it is fired like practically every other event in the .Net framework. The answer is not too many people.

It's generally speaking a bad idea to break established patterns unless there is a very compelling reason to do so.