When and why you should be using Threads

Quite often I see people making programming mistakes that will cost them dearly in the long run. They'll do things like use App.DoEvents to keep UI updating properly, or they'll make their program inaccessible by leaving tight loops run with no way to cancel them. These situations are perfect examples of when you should be using a thread.

Before we get to code, I'm going to explain a bit more about how threads work under the hood. A thread is nothing terribly special or magical. It's simply a way to slice program execution into discrete bits. I'm going to speak in some general (and in some cases not 100% technically correct, but easier to understand than the technical explanation) terms about how threads work in REALbasic.

When you create a thread, we create a data structure that points to the next bit of code to execute. Initially, this points to the Run event of the thread, and as the thread is executing, this instruction pointer is adjusted. The data structure keeps other pieces of information around as well (such as priority, current state, etc) so that the thread scheduler can do its job. In actuality, we're keeping a reference to an OS thread around and our thread scheduler actually controls (via OS calls) the OS thread the data structure owns. However, the concept is still generally the same -- it's only due to mundane reasons that we're forced to do it this way.

One thing to keep in mind is that a CPU can only execute one "bit" of code at a time. So even when using a thread, your application is running in a linear fashion. However, because the threads have such small (in human terms, but not in computer terms) slice of time that they are executing, it appears that threads run in parallel to one another. But it's important to keep in mind that only a single chunk of code is executing at a time.

There are two different threading models that are commonly used: preemptive threads and cooperative threads. With a preemptive thread, the OS has a set time slice that each thread executes in. When the thread's time slice is done, then the OS switches to another thread immediately. This causes all sorts of headaches for the programmer because that context switch could be happening in the middle of executing a line of code. This means you need to take special care when accessing any shared data and you can't make assumptions about what code has been executed between threads. Basically, it's much (much) easier to crash your application in strange and hard to reproduce ways when using preemptive threads. Thankfully, REALbasic uses the other threading model: cooperative. In this model, the threads need to cooperate with one another by telling the OS "I'm done now, please switch me out." We do this switching for you at certain boundary cases -- while evaluating a looping construct (like for or while loops), at the end of methods, etc. The downside to cooperative threads is that external (to the REALbasic framework) code needs to be able to alert the framework that a context switch is ok to do. We give plugin authors a way to do this, however, not all of them do it. And calling into declares certainly don't have a way to do this. More on this later.

So now that you know a bit more about threads in a general sense, let's talk about some design decisions you can make for your application so that you're using threads properly.

Let's say you've got a number crunching application -- you're calculating the next digit of PI. But since this is a long operation, you want your UI to still be useable so that the user can do things like select menu items or click on a Cancel button.

This is a perfect time to use threads! If we put the processing code into a thread, then it can run "in the background" while your application's main thread is allowed to keep the UI functional. The way that I usually structure this type of solution is with a message passing interface. This lets the thread update whatever is controlling it (so you can do things like update a StaticText, etc), and the controller can update the thread by calling methods on it.

So let's start with our interface:
[rbcode]
Interface MessageReceiver
Function ReceiveMessage( msg as String, data as Variant ) as Variant
End Function
End Interface
[/rbcode]
The interface is quite simple -- it lets the thread send a generic message along with a "cookie" of data. The receiver can then return some information back to the calling Thread. With this sort of generic interface, you can write code that both pushes information onto the controller as well as pulls data from it. Like this:
[rbcode]
call mReceiver.ReceiveMessage( "UI Update", "93% done processing" )
someInput = mReceiver.ReceiverMessage( "Get Input", nil )
[/rbcode]
Now, let's take a look at the thread.
[rbcode]
Class MySpiffyThread inherits Thread
Private Dim mReceiver as MessageReceiver
Private Dim mDone as Boolean

Sub Constructor( msg as MessageReceiver )
mReceiver = msg
mDone = false
End Sub

Sub Terminate()
mDone = true
End Sub

Sub Run() Handles Event
// Do some initialization stuff here

while not mDone
// Do some processing here
call mReceiver.ReceiveMessage( "Update", someUpdateValue )
wend

// Do some clean up processing here.
if not mDone then
call mReceiver.ReceiveMessage( "Done", results )
else
call mReceiver.ReceiveMessage( "Cancelled", nil )
end if
End Sub
End Class
[/rbcode]
Now we just need to see how to implement the other end of the example -- the controller. We'll use a Window to complete this example, but technically, you could use anything to control our Thread. First, create a Window and set its interfaces property to MessageReceiver. Now, in the form editor add a PushButton and set its text to Start and name it StartButton. Then, add another PushButton and set its text to Cancel (be certain to set its Cancel property to True as well), and its name should be CancelButton. Also, let's add a StaticText so we have a way to display status information. Then switch into the code editor. We need to add some code so that we satisfy the interface contract, as well as control our thread.
[rbcode]
Class Window1 Inherits Window Implements MessageReceiver
Private Dim mThread as MySpiffyThread

Function ReceiveMessage( msg as String, data as Variant ) as Variant
select case msg
case "Update"
StaticText1.Text = data.StringValue
case "Done"
MsgBox "Finished, with results: " + data.StringValue
case "Cancelled"
MsgBox "User cancelled the operation"
end select

return nil
End Function

Sub CancelButton.Action()
// We want to cancel the thread
Thread1.Terminate
End Sub

Sub StartButton.Action()
if mThread <> nil then return

// Create the thread
mThread = new MySpiffyThread( self)

// Run it
mThread.Run
End Sub
[/rbcode]
Ta da! You now have a threaded application where the thread does all the processing, and the main thread can still update all the UI.

However, if you try this out, you'll notice that your processing takes a lot longer. That's because the main thread has the same priority as the thread you created. The default priority for threads is 5. So let's talk about priorities a bit.

The way priorities work in REALbasic is that they are all relative to one another. So if you have two threads whose priorities are 5, then there are 10 total time slices for the application, and each thread gets 5 of them. If you have one thread with a priority of 10 and another with its priority as 5, then there are 15 total time slices and one thread gets twice as much CPU time as the other.

Back to our example. The problem we want to solve is that we want the worker thread to get a lot more processing time than the main thread. The main thread is just there to process the UI which doesn't take much effort. But the worker thread is there to crunch numbers and do other hard things, so we want it to get most of the CPU's time. So let's change the worker's priority!

I'd say that the UI only needs to get about 10% of the CPU time to be considered responsive. I just pulled this number out of thin air though, so you may want to fiddle with the numbers. In any event, that means we want the main thread, whose Priority is fixed at 5, to be 10% of the thread's priority. 10% of 50 is 5, so we've just found the thread's priority. Let's set it:
[rbcode]
Sub StartButton.Action()
if mThread <> nil then return

// Create the thread
mThread = new MySpiffyThread( self)

// Set its priority
mThread.Priority = 50

// Run it
mThread.Run
End Sub
[/rbcode]
Now the thread runs and uses 90% of the total application's CPU time to do its processing. You should see a significant boost in your thread's execution time now since the application isn't "wasting" a lot of its time in updating the UI.

So now that you've seen how to properly use a thread, let's talk about some of the pitfalls that people run into when working with threads in REALbasic.

One common mistake that people make when using threads is putting declare code into a thread. Don't bother. Declares have no way of calling back into the REALbasic framework to let it know when to do a context switch. So your thread will continue to use the CPU the entire time you're in the declared code. It's not until execution control comes back to REALbasic that the context switch will happen. So if you have a drawn-out declare, putting it into a thread won't help in any way. There are certain calls that REALbasic code makes that have this issue as well -- for example, FolderItem.CopyFileTo or MoveFileTo. Once the framework calls into an OS function, thread context switches cannot happen. It's unfortunate, but it's the price you pay for having an easy threading model that's very forgiving.

Another common mistake that I've seen is people thinking that threads are a panacea and will solve all sorts of speed problems. They won't -- remember, threads take up CPU time and all your code is executed in a linear fashion. This means that threads will actually slow your code down! Think about it for a moment: if your computing operation takes 10 seconds while using 100% of the CPU, it'll take 20 seconds if it only gets 50% of the CPU. However, the slowdown usually isn't a big deal for two reasons: 1) you can control how much CPU time a thread gets by changing priorities and 2) the slowdown doesn't matter since the goal is to keep the UI updating. Users only notice "lockups" when you're processing because of some visual or feedback cues that tell them the application is locked up. If the application never locks up, they're usually happy (within reason, of course).

I think that covers the majority of the information about threads themselves and how to use them within REALbasic. Perhaps in a future article I'll talk about resource management between threads and how to properly use the locking mechanisms REALbasic provides. Until next time, happy coding!