Reputation: 132264
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.
Upvotes: 16
Views: 20331
Reputation: 73173
You could use any of these:
bool isUIThread1 = SynchronizationContext.Current != null;
bool isUIThread2 = Application.MessageLoop;
bool isUIThread3 = Thread.CurrentThread.GetApartmentState() == ApartmentState.STA;
For SynchronizationContext.Current
to have a value, the first form should be shown. Its also possible to setSynchronizationContext.Current
to something from non-UI contexts as well as to set it to null from UI context (this is often seen to by-pass UI deadlocks). So in a way it is not completely reliable.
Application.MessageLoop
is a better choice but that again requires the message pump to be started (i.e. first form shown).
GetApartmentState
can be used in your Main
method, even before showing any form but you need [STAThread]
set on Main
. It would be extremely rare for serious applications to miss that. In a way this approach is the soundest.
For all practical purposes you can use any of those.
Upvotes: 4
Reputation: 2501
There is no answer for WPF yet, so for the record, in WPF you can use the return value of Application.Current.Dispatcher.CheckAccess()
to know if you are on the GUI thread or not.
It returns true
if the current thread is the UI thread in WPF.
Upvotes: 7
Reputation: 158309
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.
Upvotes: 13
Reputation: 111
bool isMessageLoopThread = System.Windows.Forms.Application.MessageLoop;
Upvotes: 11
Reputation: 1500515
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.
Upvotes: 7