How to detect if we're on a UI thread?

Question

For the sake of argument, consider a UI thread as a thread that has had a call to Application.Run() or one of it's overloads called on it and has an active message loop running.

Is there a way of detecting if we're currently executing on such a thread?

The reason I want this is because I have a class with a private function that is long-running. The class itself is already multithreaded, and the usage of this class is such that it might be used from either the UI or from background threads doing processing. This function also falls into this net. But I don't want it to block up the UI thread. So I want to detect if I am running on a UI thread and if so, fork the function call into a background thread (probably ThreadPool, but that's a non-issue for this discussion). This is entirely well-behaved, but the background threads are probably relying on the output of the function, so blocking for them is better, whereas the UI thread is accessing it in a more "set-and-forget" manner.

Answer 1

If you have access to a Form or a Control, you can check the InvokeRequired property; this will return false if you are on the UI thread and true if you are not.. If it happens in a context where you cannot check against a Control, you could easily set up a static property in your program that you could check against. Store a reference to Thread.CurrentThread at startup, and compare Thread.CurrentThread to that reference when you need to know:

static class Program
{
    private static Thread _startupThread = null;

    [STAThread]
    static void Main()
    {
        _startupThread = Thread.CurrentThread;

        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }

    public static bool IsRunningOnStartupThread()
    {
        return Thread.CurrentThread == _startupThread;
    }
}

By calling Program.IsRunningOnStartupThread you will get a bool saying if you are or not.

Answer 2

bool isMessageLoopThread = System.Windows.Forms.Application.MessageLoop;

Answer 3

I would suggest that it's the kind of decision the caller should make. You could always write wrapper methods to make it easier - but it means that you won't have problems with the caller being in an "odd" situation (e.g. a UI framework you don't know about, or something else with an event loop) and you making the wrong decision for them.

If the method ever needs to provide feedback in the right thread, I'd pass in an ISynchronizeInvoke (implemented by Control) to do that in a UI-agnostic way.