3

I think the answer is no. I checked similar questions on stackoverflow, but they seem to go different directions based on what was needed for the specific solutions (but may have missed something).

Is it ever possible to have more than a single UI thread in a WinForms application? I am refactoring and wondering if I should use ConcurrentDictionary or Dictionary that would be accessed from those thread(s) accessing forms. This is for a larger body of code with multiple developers/designs and I want to make the choice as solid as possible (but not over engineer it). Since I am looking for a general answer, specifics are not in this question although they usually are. Thanks for looking and any help - much appreciated.

Buck
  • 599
  • 7
  • 20
  • 2
    The answer is yes, although it's infrequently done. You can have a distinct thread for each form (although each control would only have one associated UI thread). http://dotnetbeyond.blogspot.com/2011/10/multiple-ui-threads-in-winforms.html – Douglas Feb 12 '14 at 13:13

2 Answers2

5

Yes it can be done, but it's usually wrong to do so. Multiple UI Threads - Winforms

Every sensible GUI design I've ever encountered always uses a single UI thread, even if the framework allows for more than that. The single exception I can see are independent windows living in their own threads and accessing shared data from a Model that lives in a different thread, but the benefits from such a design are limited. (Edit: In some cases a better alternative to using multiple UI threads is to use different processes for different windows - like tabs in browsers - as this allows the main application to recover e.g. if a window corrupts the heap.)

However, for any reasonably advanced application there will be multiple non-UI background threads.

Because you are asking in the context of thread-safety, I'd suggest keeping the MVVM and MVP patterns in mind. If your structure lives in View, Presenter, or ViewModel, it doesn't need thread safety. The Model often lives in, or talks with, a different thread - e.g. if it's a database or a wrapper over a database. So threadsafety is usually part of the design of the Model, or part of the communication of the Model with the ViewModel/Presenter.

See MVVM: Tutorial from start to finish?, What are MVP and MVC and what is the difference?

Community
  • 1
  • 1
Peter
  • 5,608
  • 1
  • 24
  • 43
  • I wouldn't say that it's "usually wrong" to use multiple UI threads. The trend today is to parallelize even the UI. Modern web browsers create a new thread (or even process) for each tab; there's no reason why other applications shouldn't do the same. – Douglas Feb 12 '14 at 13:29
  • Using an independent process per tab is done to shield them from each other, which is a major benefit. The benefit of simply using an additional UI thread is much less than the benefit of a different process (which can crash and be restarted on it's own), for example to provide access to legacy functionality. I've just seen more wrong examples than right examples, which is why I say it's usually wrong - but I agree that this is an opinion. – Peter Feb 12 '14 at 13:34
4

Yes, it’s perfectly possible if you need to. Here is an example of the form that spawns threads with new instances of the same form:

public partial class Form1: Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void button1_Click( object sender, EventArgs e )
    {
        Thread t = new Thread( ThreadProc );
        t.Start();
    }

    static void ThreadProc()
    {
        Application.Run( new Form1() );
    }
}

But, designing multithreaded GUI is not necessarily a good idea. You have to understand the consequences. I suggest you read the MSDN article about the subject. It’s from 1993, however the only deprecated parts are about migration from windows 3.1.

Soonts
  • 20,079
  • 9
  • 57
  • 130