Click here to Skip to main content
14,663,957 members
Articles » Web Development » User Controls » General
Article
Posted 6 Dec 2007

Stats

94.1K views
1K downloads
36 bookmarked

An Alternate Way of Writing a Multithreaded GUI in C#

Rate this:
1.76 (36 votes)
Please Sign up or sign in to vote.
1.76 (36 votes)
18 Dec 2007CPOL
An article on writing a responsive multithreaded GUI, but not the Microsoft way
Screenshot - GUIThreads1.JPG

Introduction

This article outlines an alternate method of writing a responsive multithreaded Windows Forms GUI in C#. When I say "alternate," I mean a technique that does not follow the current Microsoft mantra that only the thread that created a GUI control should interact with it. This technique should only be considered when one or more controls in your GUI are processing tens or hundreds of messages a second, causing the GUI to become unresponsive. Typically this is true when using real-time data feeds. The controls in question should be read-only, not updated via the GUI. In all other cases, the standard BeginInvoke/SycnchronizationContext/AsyncOperation calls should be used. For the majority of Windows Forms GUIs, this technique is not appropriate.

Background

Many years ago when I was writing real-time C Windows applications, it was not uncommon to associate several threads with several of the application's child windows in order to improve the responsiveness of the GUI. Over the years, this technique has been used (and documented) less and less. Originally, Microsoft documented and encouraged developers to use this technique. Today, the technique has become totally taboo. It's gotten to the stage now that when I discuss this technique with other .NET developers, they don't even believe it will work. Through this article, I intend to show that in some situations (see Introduction) it is perfectly all right (and safe) to update GUI controls from other threads.

The Sample Code

The sample application is a very basic proof-of-concept skeleton. It contains no validation or exception handling code. Obviously, this would not be the case in production code. The first thing the sample code does is create the threads to be associated with the selected main form's child controls and get them running. This is done in the main form's Load event handler.

private void theMainForm_Load(object sender, EventArgs e)
{
    // Prevent the framework from checking what thread the GUI is updated from.

    theMainForm.CheckForIllegalCrossThreadCalls = false;

    // Create our worker threads and name them.

    // The name will be used to associate a thread with a specific ListView
    worker1 = new Thread(new ThreadStart(UpdateListView));
    worker1.Name = "Worker1";

    worker2 = new Thread(new ThreadStart(UpdateListView));
    worker2.Name = "Worker2";

    worker3 = new Thread(new ThreadStart(UpdateListView));
    worker3.Name = "Worker3";

    worker4 = new Thread(new ThreadStart(UpdateListView));
    worker4.Name = "Worker4";

    // Get all the threads running.

    Start();
}

Notice in the above code that we set the form's CheckForIllegalCrossThreadCalls property to false. This property was added in .NET 2.0. If this was not set to false, the framework would throw InvalidOperationException at run-time, as can be seen below:

Screenshot - GUIThreads2.JPG

The UpdateListView method that is executed by the threads simply fills and then empties its associated list view over and over until it is told to stop. In a more realistic scenario, the thread would probably wait on a synchronization object. When the object is signaled, the thread would probably process any items in a work queue associated with the control. Here's the UpdateListView method:

private void UpdateListView()
{
    ListView lv         = null;
    ListViewItem item   = null;
    string name         = Thread.CurrentThread.Name;
    int loopFor         = 20;
    int sleepFor        = 25;
    int count           = 0;

    switch (name)
    {
        case "Worker1":
            lv = listView1;
            break;
        case "Worker2":
            lv = listView2;
            break;
        case "Worker3":
            lv = listView3;
            break;
        case "Worker4":
            lv = listView4;
            break;
    }

    // Keep running until we're told to stop.
    while (run)
    {
        // Add n items to the list.
        for (int i = 0; i < loopFor; ++i)
        {
            item = new ListViewItem(DateTime.Now.ToString("HH:mm:ss.ffff"));
            item.SubItems.Add(string.Format("{0}: item {1}", name, ++count));
            lv.Items.Insert(0,item);
            Thread.Sleep(sleepFor);
        }

        // Now remove them.
        for (int i = 0; i < loopFor; ++i)
        {
            lv.Items.RemoveAt(0);
            Thread.Sleep(sleepFor);
        }
    }
}

Running the Sample Application

When you start the sample application, the four ListView controls will immediately start filling with text and then emptying. While this is happening, try resizing the form. Update the status bar text or display the modal About dialog from the main menu. Drag the ListViews column headers around to re-order them. Click the column headers several times to sort the columns in ascending or descending order. This is all thread-safe.

See how responsive the application feels despite all the activity in the ListView controls. This is due to the fact that all of the heavy work is being done in the background by the four threads associated with the ListView controls. All of the other controls on the form are going through the main GUI thread. Before the application can be closed, the "End Loop" button must be pressed in order to terminate the four threads associated with the four ListView controls.

Performance

Provided that care is taken to enforce that only the thread associated with a particular control is allowed to update its content (either its items collection or data source), this technique can produce an extremely fast and responsive GUI. An additional benefit can be seen in the simplification of the code, as no calls to InvokeRequired(), BeginInvoke() or EndInvoke() are required. In addition, the performance overhead of marshaling calls onto the GUI thread has also been removed. If speed in the Windows Forms GUI is your top priority, you might want to give this technique a try.

Miscellaneous Notes

Please remember that as this is a technique not often seen, so make sure your code is heavily commented to protect the innocent. This code was developed using Visual Studio 2005.

History

  • 7 December, 2007 -- Original version posted
  • 18 December, 2007 -- Updated sample code and text to clarify my intent

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Keith Balaam
Software Developer Oliguy Limited
United Kingdom United Kingdom
No Biography provided

Comments and Discussions

 
GeneralBackground Worker Pin
Angelo Cresta18-Dec-07 22:37
professionalAngelo Cresta18-Dec-07 22:37 
QuestionCan it get any simpler than that? Pin
Grommel10-Dec-07 3:00
MemberGrommel10-Dec-07 3:00 
AnswerRe: Can it get any simpler than that? [modified] Pin
Steve Messer18-Dec-07 7:42
MemberSteve Messer18-Dec-07 7:42 
AnswerRe: Can it get any simpler than that? Pin
Keith Balaam18-Dec-07 9:23
MemberKeith Balaam18-Dec-07 9:23 
GeneralDoesn't always work Pin
vtweasel10-Dec-07 2:11
Membervtweasel10-Dec-07 2:11 
QuestionRe: Doesn't always work Pin
pasflug111-Nov-09 7:18
Memberpasflug111-Nov-09 7:18 
GeneralIt is a possible way.. but like everything it has it's place Pin
Jared Allen9-Dec-07 18:43
MemberJared Allen9-Dec-07 18:43 
GeneralRe: It is a possible way.. but like everything it has it's place Pin
Keith Balaam18-Dec-07 9:12
MemberKeith Balaam18-Dec-07 9:12 
GeneralRe: It is a possible way.. but like everything it has it's place Pin
Jared Allen18-Dec-07 9:24
MemberJared Allen18-Dec-07 9:24 
GeneralNice Article! Pin
Herman Schoenfeld9-Dec-07 12:43
MemberHerman Schoenfeld9-Dec-07 12:43 
GeneralLazy coding Pin
Pete O'Hanlon9-Dec-07 10:06
subeditorPete O'Hanlon9-Dec-07 10:06 
GeneralRe: Lazy coding Pin
Keith Balaam18-Dec-07 9:03
MemberKeith Balaam18-Dec-07 9:03 
GeneralUmmm....yeah Pin
Dave Kreskowiak9-Dec-07 8:52
mveDave Kreskowiak9-Dec-07 8:52 
GeneralRe: Ummm....yeah Pin
Keith Balaam18-Dec-07 8:53
MemberKeith Balaam18-Dec-07 8:53 
GeneralNot good at all Pin
Sacha Barber8-Dec-07 21:38
MemberSacha Barber8-Dec-07 21:38 
GeneralRe: Not good at all Pin
Keith Balaam18-Dec-07 8:48
MemberKeith Balaam18-Dec-07 8:48 
Generalstate machines [modified] Pin
Tomaž Štih7-Dec-07 19:05
MemberTomaž Štih7-Dec-07 19:05 
QuestionThought this was common knowledge? Pin
Dankarmy7-Dec-07 10:31
MemberDankarmy7-Dec-07 10:31 
GeneralWait a minute.... Pin
Marc Clifton7-Dec-07 10:26
mvaMarc Clifton7-Dec-07 10:26 
GeneralBad technique Pin
peterchen7-Dec-07 10:18
Memberpeterchen7-Dec-07 10:18 
GeneralRe: Bad technique Pin
Keith Balaam18-Dec-07 8:15
MemberKeith Balaam18-Dec-07 8:15 
GeneralWhy many of us consider this bad Pin
peterchen18-Dec-07 14:36
Memberpeterchen18-Dec-07 14:36 
GeneralNot thread-safe Pin
Nathan Evans7-Dec-07 10:06
MemberNathan Evans7-Dec-07 10:06 
AnswerRe: Not thread-safe Pin
Keith Balaam18-Dec-07 7:52
MemberKeith Balaam18-Dec-07 7:52 
GeneralGreat finding Pin
Roberto Colnaghi7-Dec-07 9:11
MemberRoberto Colnaghi7-Dec-07 9:11 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.