Tag Archives: multithreading

Multithreading in WPF

Posted on by

If you’re unfamiliar with multithreading, be sure to check out my previous entries on the topic.

In WPF, creating a thread is as easy as it is with C#. You can find an example on that here.  Alternatively, you could use the BackgroundWorker, which basically will create a thread and will give you a generalized, simplified interface in which to interact with it for a common threading task: doing an extra task in the background (such as downloading or progress bar updating).

In an earlier post, I used a mysterious method to enable responsiveness in the UI while loading a bunch of content (in that case, images).

This mystical object is called The Dispatcher.

THE DISPATCHER

No, this isn’t an edge-of-your-seat thrill ride movie that smacks explosions, swords, and alien guts into your M&M-filled mouth. It is an object used to manage the work for threads within WPF.  It maintains a queue of work items that are requested of any given thread, based on their order and priority.  This is the object you want to get to know if you’re going to be playing with your UI on a separate thread.

As mentioned previously, UI objects can’t be accessed outside of the threads that created them.  You can, however, use a separate thread to determine what changes you’ll be making and to what objects you will make them, then use their thread to actually apply that change.  In order to do this, use the object’s dispatcher to schedule the work on their queue.

For example, take a look at the code for loading images mentioned above:

private void LoadImage(string fname)
{
	// instantiate and initialize the image source
	BitmapImage bmi = new BitmapImage();
	bmi.BeginInit();
	bmi.UriSource = new Uri(fname, UriKind.Relative);
	bmi.EndInit();
 
	bmi.Freeze();		// freeze the image source, used to move it across the thread
 
	// this method tells the separate thread to run the following method to run on the UI thread
	// the (ThreadStart)delegate(){ } notation is a shorthand for creating a method and a delegate for that method
	TheImage.Dispatcher.BeginInvoke(System.Windows.Threading.DispatcherPriority.Normal, (ThreadStart)delegate ()
	{
		TheImage.Source = bmi;
	});
}

This method creates the BitmampImage object on a separate thread, leaving the main thread free for user input, and freezes it so that it can be used on another thread.  It then uses TheImage’s Dispatcher to modify TheImage on its own thread by calling its dispatcher’s BeginInvoke method.

There are two ways to invoke using the dispatcher: BeginInvoke() and Invoke().  BeginInvoke() will queue the work for the dispatcher and continue the separate thread’s execution.  It puts in the request for the UI thread to execute the delegate, then continues on it merry way for its own execution.  This is useful when your separate thread does not rely on what it is requesting the UI thread to do.

The Invoke() method will wait until the delegate is executed and returns.  If you are modifying anything that you need or if the modification must be done before continuing in the separate thread, you should go with this one.

The Dispatcher is something you’ll get pretty cozy with if you plan on changing your UI elements from a separate thread.  If you’re just doing a progress bar or something else that is rather predictable, you can skip it by using the BackgroundWorker’s ReportProgress method and ProgressChanged event.  Just be sure to give it some time if you are calling the dispatcher often.

In case you didn’t notice all of my linking to previous posts, you may want to check out the rest of my posts on multithreading.

Threading Complexities

Posted on by

As I explained previously, threads are like workers with separate to-do lists that share the same tools and materials and perform tasks at the same time. There are a couple of tough situations that these coworkers will often find themselves in, however, and you need to make sure that their employer has the proper processes to provide solutions.  Yes, I am going to run this metaphor straight into the ground.

First, you need to know what “concurrent” means to a computer.  Dictionary.com defines it as “occurring or existing simultaneously or side by side”.  Your computer, however, defines it as “switching between the tasks fast enough so that nobody notices that they aren’t occurring simultaneously”.  So, when I say that your employees are working at the same time, I actually mean that they are working one at a time but switching between who is working fast enough that the boss doesn’t realize they’re taking breaks.  The CPU is constantly juggling which thread gets to execute, based on priority and (usually) the order by which they come.  This same kind of exercise is happening with all of the processes that are currently running.

If you don’t notice, why should you care?  Well, there is a delay when switching between threads (or processes) called a context switch.  During a context switch, the CPU must save the state of the currently active thread, choose the next thread to give time to, restore that thread’s state, and continue its execution.  What this boils down to is that there is cost a  associate with multithreading.  You need to be aware of this cost, otherwise you may find your application running slower with multiple threads.  The reason is that your threads are unbalanced – that they are switching back and forth so much that the time it takes to do all of the context switching is greater than the time you save running two tasks simultaneously!

I ran into an example of this recently when attempting to improve the responsiveness of an application.  I was trying to do things on a separate thread to keep things smooth in the UI for the user; however I had to perform a task on a set of elements on the original thread (more on that later).  This forced me to call back to the original thread so often that the experience ended up being even worse.  I’ll explain more detail about how that works in WPF in a future post, but here’s the basic idea in pseudocode:

create a new thread to perform a CPU-intensive task; run:
   foreach object in somelist
      call back to original thread with the following task:
         perform an action on object

Because I went back to the original thread so often and so quickly, the CPU was spending most of its time context switching.  In order to fix it, I added one line:

create a new thread to perform a CPU-intensive task; run:
   foreach object in somelist
      call back to original thread with the following task:
         perform an action on object
      sleep for x amount of time

I added a sleep command in the separate thread.  This gave the main thread time to perform the task on the object, redraw, and settle in a little before I gave it another task.  This added a visual delay to the action on-screen (since there is x amount of time between each object being acted upon), but that was acceptable in this case to give the user a smooth experience.

Secondly, there is a key part of this metaphor that you have to consider: each worker is sharing resources.  This is good – it means that each thread can access the data it needs while executing; however, it comes with a caveat: you have to ensure no thread is changing that data while another thread is trying to access it.

Imagine if we have two workers sharing a drill.  Worker One is going to use it to screw a shelf to a wall, while Worker Two is going to drill a hole for the next shelf.  Now, imagine that Worker One has placed the screw where he wants it and is about to pull the trigger on the drill when a context switch occurs.  Worker One freezes, and Worker Two grabs the drill.  He pulls out the Phillips head bit that Worker One was using and replaces it with a drill bit.  Like an episode of Seinfeld, the worst thing happens at the worst possible time: another context switch.  Worker one takes the drill back and uses the drill bit on his screw, damaging the screw and quite possibly his hand.  This is called a race condition: multiple independent algorithms are dependent on a single shared resource, thus making the timing of each access of that resource critical to the success of each algorithm.

This means you have to be weary of using your global variables or the members of your class in a thread.  You must be certain that you aren’t changing something that your other thread is depending on.  The common way to handle this is by using mutual exclusion (or mutex) algorithms.  The basic concept is that, when using a variable that is common to other threads, you must ensure that the variable is not currently in use by another thread, often via queues or access flags.  Take a look at the previous link for a list of well-known algorithms with examples.  There is a wealth of knowledge related to solving race conditions, and I’m not even going to attempt to address it all.

If you take a close look at the pseudo code above, you’ll notice that I’m using a single thread to perform all actions on the set of objects, thus avoiding race conditions (as only one thread accesses them at a time).  This isn’t by my own design, however; this is a restriction given to UI elements in most, if not all, languages.  Because of their nature, UI elements aren’t thread safe.  They can be accessed by you, the graphics engine, or even the user.  Because of the amount of overhead required to allow UI elements to work in threads, they are restricted to being accessed only by the thread that created them.  Above, since I cannot access the UI elements in my worker thread, I have to call back to the thread that created the object and tell it to do the modifications I need.  This makes moving work to separate threads in a UI-heavy application complicated at times, but you get used to it pretty quickly.

So, it doesn’t sound near as simple as it did in my first post; however, don’t let this scare you away from using multithreading.  Once you get the hang of it, it is really quite simple to use.  Besides, you’ll need to be familiar with it before digging your hands into any serious user-oriented application.

Introduction to Threads

Posted on by

Threading is a pretty core concept, but I felt it might be necessary to give it a brief explanation before moving on to some WPF-specific concerns for threads.  If you are already familiar with threads, these aren’t the droids you’re looking for.

If you think about the flow of a simple application that does not use multithreading, you’ll find that you can basically draw a line on a sheet of paper and label the events of the process as a straight line of consecutive actions:

simple_console_eventsThis method is often very stifling to the developer, as it limits what you can do.  At times, you want another action to be able to perform simultaneously.  A classic case is to allow a user to cancel an action.  In this case, the user is allowed to interact with the process while it is busy.  That is, the line of execution cannot be drawn so straight:

Threaded ExecutionYou can perform this (seemingly) concurrent operation by using threads.  Threads are similar to processes in that they are a set of instructions for the computer to perform; however, processes and threads differ in that separate threads share resources under the same process, while processes are independent of each other.  You can think of separate threads as workers who share materials and tools, but have separate instructions to perform at the same time.

Every application has at least one thread: the main thread of execution.  This is represented by the green line above; it is the thread that starts the application and is the top of the family tree of the cute little baby threads that are spawned during your application’s execution.  When you have an action that you wish to perform concurrently with the main thread, you create a new thread, give it a set of tasks, and start its execution.  In C#, simply instantiate a Thread object using a delegate and start it.

Thread worker = new Thread(delegate()
   {
      // actions to perform on separate thread
   });
worker.Start();

A delegate is a reference type to a function that serves to give the thread an action to perform. So, if you think of a thread as a worker separate from the main thread, you can think of a delegate as that worker’s to-do list.

In C#, there is also a Delegate class. This class is used as a base for derived delegates – you can use this if you want to have a custom delegate, which is useful for defining to-do lists that have specific requirements. For example, events use custom delegates in order to ensure that the event handler has the proper information when it reacts to the event. So, if you want to create a MouseDown event handler, you must define a handler that accepts the sender of the event, as well as information regarding the mouse’s state.

Seems simple enough, right?  Well, things can actually get quite complicated.  I’ll address some complexities of multithreading in another post.

Just a Bit: Loading Images Asynchronously in WPF

Posted on by

Multithreading using WPF is a little tricky at first (I’m planning a more thorough post on that later), but the basic thing you need to know is that you can’t access WPF elements outside of the UI thread, because they aren’t thread safe.  There are some things you can do to speed loading up, however.  Here’s a method for loading images on a separate thread:

private void LoadImage(string fname)
{
	// instantiate and initialize the image source
	BitmapImage bmi = new BitmapImage();
	bmi.BeginInit();
	bmi.UriSource = new Uri(fname, UriKind.Relative);
	bmi.EndInit();
 
	bmi.Freeze();		// freeze the image source, used to move it across the thread
 
	// this method tells the separate thread to run the following method to run on the UI thread
	// the (ThreadStart)delegate(){ } notation is a shorthand for creating a method and a delegate for that method
	TheImage.Dispatcher.BeginInvoke(System.Windows.Threading.DispatcherPriority.Normal, (ThreadStart)delegate ()
	{
		TheImage.Source = bmi;
	});
}

The meat of the method is the BitmapImage.Freeze method – this is specifically useful for loading images.  The Dispatcher.BeginInvoke is also important, but I’ll leave more explanation on that for the threading post.