C# App: Asynchronous Events Help

[slikrik98]

Greetings,

I believe I have narrowed down my issues to one simple question, and I'm hoping someone with async events experience can help me out.

My question is: how is using EventsHelper.Fi reAsync() different from using EventsHelper.Fire() BUT having the listener's event handler spawn a new thread to do the work?

In my program, I have a data feed coming in and I have a separate form that has a DataGridView on it. Each time a message comes in (they come in very rapidly) I fire an event and the handler (which exists on the DataGridView's form) adds a row to the DataGridView.

Approach #1: use EventsHelper.Fi reAsync() to fire the events as they come in. This is nice because the slowness of adding rows to the DataGridView control doesn't slow down the incoming data feed AT ALL -- meaning, if there were other listeners to this event, their performance wouldn't suffer from the slow DataGridView. HOWEVER, this approach doesn't work because of the asynchronous nature, the rows aren't necessarily added in order (message 3 might be processed/added to the DataGridView before messages 1 and 2).

Approach #2: use EventsHelper.Fi re() (the synchronous version), and in the event handler, spawn a BackgroundWorke r that adds the message to the DataGridView. I don't like this approach because then EVERY handler of this event is going to have to do all this extra work, but I figured it was the only way I could ensure the messages (events) would be received in order. However what I noticed is this approach (spawning the BackgroundWorke r thread) doesn't really give a speed improvement over simply doing ALL the work in the same event thread.

Why isn't approach #2, with a BackgroundWorke r in the ONLY event handler as fast as approach #1?

I love the speed EventsHelper.Fi reAsync provides, but I need to maintain order of the events. If anyone has any advice, I'm all ears.

Thanks in advance!

RL

[slikrik98]

To add to my confusion, I add a Thread.Sleep() call in my BackgroundWorke r's DoWork() function, and this allows the main (event-generating) thread to get through all of the messages quickly! Why should it matter if there's a Sleep call in the background worker's thread -- if it's on a separate thread, shouldn't the main (event-generating) thread be allowed to continue?

void bw_DoWork(object sender, DoWorkEventArgs e)
{
    OrderUpdateEventArgs updateEvent = (OrderUpdateEventArgs)e.Argument;
    if (updateEvent.GetEventType() == OrderUpdateEventArgs.OrderUpdateEventType.EVENT_TYPE_FILL) {
        Thread.Sleep(200);  // this speeds up the calling thread!  why!?
        PerformTimeIntensiveTask();
    }
}
void controller_OrderUpdated(object sender, OrderUpdateEventArgs updateEvent)
{
    BackgroundWorker bw = new BackgroundWorker();
    bw.DoWork += new DoWorkEventHandler(bw_DoWork);
    bw.RunWorkerAsync(updateEvent);
}
 

The Sleep call above allows the calling thread to process all of the messages as if there were ZERO delay from this event handler.