Creating a simple multi-threaded VB.Net application
I write lots of desktop tools that help me do my job more efficiently. For instance, I’m normalizing a 98 million row live table and do to the nature of the server, table locks, etc, I’ve decided to pull the data down in batches using a VB.Net app, analyze it and perform a batch update. The high-level code is simple: pull the data, group it and then execute some UPDATE SQL statements. But 98 million rows in a partially non-indexed table takes a looooong time, and maybe its my agency background, but I want some feedback as to what’s going on, and I want more than just a Trace/Console output. At first glance you might just add a progress bar and update it every time you do something, but unfortunately your code loop will block the UI thread from updating until complete (although you can throw some Application.DoEvents in there).
So enter multi-threading. If you think this is overkill then a) you obviously don’t know me and b) I’ve been doing this for years, it only takes a little bit more work to add it. The code below will show you how to create a multi-threaded app with a responsive UI. The code below is all done in Visual Basic 2008 Express Edition.
1) Create a new VB.Net Windows Forms Application.
2) Add a ProgressBar and a Button to the form, leave the names the default names
3) Resize the ProgressBar so you can see more of it
4) Double-click the Button to go into code-behind
5) Add a new class to the project called “Worker” and add the following code to it:
This code will be doing our primary work. In this case its not actually doing anything except sleeping, you’ll want to replace the System.Threading.Thread.Sleep(250) with your own logic, obviously. We’ll instantiate this code in our primary UI thread later, telling it how many times we want it to loop. I always prefer to pass my required variables in the constructor and make them read-only properties so that I know that they’ll be set. One other thing that you’ll notice, usually in the For loop you’d do something like For I = 1 to Me._maxRuns. creating a local counter variable. Instead, our code creates a class-level variable and gives read-only permission to it so that other code (on another thread) can determine where we’re at. That’s it from the worker class’s point of view. The only bit of thread-related code in here is the Sleep method and that’s for example purposes only.
The next step is to add some logic to the main form’s code-behind to create our worker, create a thread to execute the worker and create a thread to monitor the worker and report back to the form and changes. Before I slap the code up let me explain how it will work. After clicking the button the form’s primary (and only, initially) thread will create an instance of the Worker class. It will then create a new Thread object and tell it that when we execute it it should call the Worker’s Start() method. This alone would give
you a responsive UI but unfortunately the Worker thread can’t safely update the UI because they’re on different threads (and VS 2008 will actually throw errors if you try). You can get around this using events or delegates in the worker object but I prefer to make my worker object 100% completely thread un-aware, meaning that it doesn’t report back to anyone, it just does the work and if someone wants to inspect its progress, fine, but it doesn’t really care. So how do we do this? We introduce a third thread whose only job is to check the status of the worker object and tell the main thread to update the progress bar. The code is so simple that I don’t even bother wrapping it in a separate class, I just include a Monitor() method in the form’s code-behind. The code runs a loop until the worker thread signals that its done, sleeping for a bit between each loop so that we don’t flood the UI with update calls (there’s no sense in sending “set the progress bar to 1″ a million times a second). Threads automatically handle adjusting their ThreadState so we don’t have to worry about that.
One last thing. Debugging a multi-threaded program can be a PITA so one of the things that I do is include a switch to turn it on or off as needed. I prefer to do this with a Compiler Directive by adding #Const MULTI_THREADED = True to the top of my code-behind. Then there’s just a simple change to the button’s click event:
When MULTI_THREADED is False we’ll invoke the worker, blocking the UI thread from ever updating, do the work and reset the button. This can save you a lot of time when debugging. This is also why I like to keep my worker object thread un-aware.