In WinForms, why can't you update UI controls from other threads?

Question

I'm sure there is a good (or at least decent) reason for this. What is it?

Answer 1

It is so that you don't have two things trying to update the control at the same time. (This could happen if the CPU switches to the other thread in the middle of a write/read) Same reason you need to use mutexes (or some other synchronization) when accessing shared variables between multiple threads.

Edit:

In other languages such as C++ you are free to try and do this (without an exception being thrown as in WinForms), but you'll end up learning the hard way!

Ahh yes...I switch between C/C++ and C# and therefore was a little more generic then I should've been, sorry... He is correct, you can do this in C/C++, but it will come back to bite you!

Answer 2

Because you easily end up in a deadlock situation. I.e. your secondary thread will be trying to update the UI control, but the UI control will be waiting for a resource locked by the secondary thread to be released, so both threads end up waiting for each other to finish.

In other languages such as C++ you are free to try and do this (without an exception being thrown as in WinForms), but you'll end up learning the hard way!

[Edit]

Incidentally, you can easily tell the UI thread that you want to update a control, just create a delegate, then call the (asynchronous) BeginInvoke method on that control passing it your delegate. E.g.

myControl.BeginInvoke(myControl.UpdateFunction);

This is the equivalent to doing a C++/MFC PostMessage from a worker thread

Answer 3

Back in 1.0/1.1 no exception was thrown during debugging, what you got instead was an intermittent run-time hanging scenario. Nice! :) Therefore with 2.0 they made this scenario throw an exception and quite rightly so.

The actual reason for this is probably (as Adam Haile states) some kind of concurrency/locky issue. Note that the normal .NET api (such as TextBox.Text = "Hello";) wraps SEND commands (that require immediate action) which can create issues if performed on separate thread from the one that actions the update. Using Invoke/BeginInvoke uses a POST instead which queues the action.

More information on SEND and POST here.

Answer 4

There would also be the need to implement synchronization within update functions that are sensitive to being called simultaneously. Doing this for UI elements would be costly at both application and OS levels, and completely redundant for the vast majority of code.

Some APIs provide a way to change the current thread ownership of a system so you can temporarily (or permanently) update systems from other threads without needing to resort to inter-thread communication.

Answer 5

I think this is a brilliant question - and I think there is need of a better answer.

Surely the only reason is that there is something in a framework somewhere that isn't very thread-safe. Is it a problem with .NET or Win32 - and why isn't there a push to fix the source instead of enforcing what, to me, feels like a nasty work-around?

Anyone know where the real underlying issue is?

Answer 6

I think this is a brilliant question - and I think there is need of a better answer.

Surely the only reason is that there is something in a framework somewhere that isn't very thread-safe.

That "something" is almost every single instance member on every single control in System.Windows.Forms.

The MSDN documentation for many controls in System.Windows.Forms, if not all of them, say "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

This means that instance members such as TextBox.Text {get; set;} are not reentrant.

Making each of those instance members thread safe could introduce a lot of overhead that most applications do not need. Instead the designers of the .Net framework decided, and I think correctly, that the burden of synchronizing access to forms controls from multiple threads should be put on the programmer.

[Edit]

Although this question only asks "why" here is a link to an article that explains "how":

How to: Make Thread-Safe Calls to Windows Forms Controls on MSDN

http://msdn.microsoft.com/en-us/library/ms171728.aspx

Answer 7

Although it sounds reasonable Johns answer isn't correct. In fact even when using Invoke you're still not safe not running into dead-lock situations. When dealing with events fired on a background thread using Invoke might even lead to this problem.

The real reason has more to do with race conditions and lays back in ancient Win32 times. I can't explain the details here, the keywords are message pumps, WM_PAINT events and the subtle differences between "SEND" and "POST".

Further information can be found here here and here.

Answer 8

Hmm I'm not pretty sure but I think that when we have a progress controls like waiting bars, progress bars we can update their values from another thread and everything works great without any glitches.