Asynchronous Thread Calls With Delegates

Introduction

This is a small example for doing asynchronous operations on Windows Forms by using delegates. As this article is mostly about using Asynchronous Thread Calls, there is nothing really fancy going on inside the application. But this article can be a useful piece of information in async operations. The required code explanatios can be found inside the project itself.

Purpose, Pros, and Cons

This actually is a different - and probably a rare approach for working on asynchronous operations. Basically, delegates are used to invoke different non-returning (void) functions. By doing this, you may achieve smoother and less "laggy" experience on your applications, when you need to make some heavy duty work such as large number calculations, massive I/O operations and even for working with web based applications (such as using web services etc.)

As a simple example, when calling loads of data from a database, it may take a while to load and show your data to user. In this scenario, user may think the application is in a deadlock or there has been a failure in the application. To prevent these, the user needs to see what's actually happening in the background. By using this method, the user will be able to make other operations (if possible) on the form, move the form itself, resize it and every other things that can be done.

However, there is one main drawback for this method, and that would be the part where Control.CheckForIllegalCrossThreadCalls = false; goes. Even though Microsoft has allowed developers to bypass Illegal Cross Thread Calls Checking, using it is considered as bad practice by most of the developers. But why it is a bad practice and what does it do actually?

At runtime phase of the application, .NET Framework checks if a control/object is being accessed and/or manipulated in an unsafe manner from another thread or threads. So basically, this controlling property comes in when there are multiple threads in an application. The property allows us to turn off the runtime check. That's why this is mostly considered as bad practice by most of the developers beacuse it is nothing but ignoring the problem that have or will occur. As most of us will agree, ignoring the problem is not the way to solve it.

So, what's the problem here? Actually there is no one problem. There might be all sorts of problems that can happen when multiple threads (or users) are trying to access and manipulate an object simultaneously, which is something even worse. So basically, the main problem is concurrency.

You can see the real trouble of illegal cross thread calls in the example below.

Let's say we have a variable called result which its type is integer. The following code multiplies its value by 2 and writes the new value to the same variable. So, even if we have more than one thread and if the threads are executed sequentially (synchronously), we will not have any problems at all. The process steps are as shown below.

result*=2;

However, if the threads are not executed sequentially, things are quite different...

As a conclusion, using Control.CheckForIllegalCrossThreadCalls is totally up to you and the structure of your application. Just to be safe, keep in mind that this property can also cause great security problems as well. So you better think twice before using it.

Using the code

Mostly, the whole thing is working through delegates and simple methods. Delegates are used to send invoke messages. In this example, there are two main methods. The first one is DoStuff(), which obviously is for doing the async work, and the second one is EndProcess() which takes IAsyncResult object as parameter. In DoStuff() method, nothing fancy is given in the example. Only changing background color and dynamically inreasing value of a variable.

public void DoStuff()
{
    for (int i = 0; i...)
    {
         //...
    }
}

Nothing extra is used in the application like external resources, images etc. The source code or the demo application can be downloaded and run easily.