UI Threading *Might* Suck

This article clearly explains the troubles needed to go through in order to interact with a Winforms UI from a background thread. I found it when I started stumbling around with my own UI, having long operations processing in the background.

It helped, but why the hell must it be this cumbersome? Basically you need a delegate and a handler method for every UI related function you'd call from your back-thread. That's amazingly tedious.

I wonder how this process can be made shorter (and/or easier). Back to digging I guess..

Until I figure this one out - the title holds :)

Published Tuesday, May 06, 2003 1:06 PM by RoyOsherove
Filed under:

Comments

Monday, May 05, 2003 11:09 PM by Michael Arnoldus

# re: UI Threading *<b>Might</b>* Sucks

Beware - I've spend quite a lot of time on this problem. We are building a client application fetching information from a server (using SOAP) in the background, and displaying the information in the windows UI when it arrives. Unfortunately it arrives in another thread. On top of this we have implemented a cache the UI components should be reading from (the cache could also be viewed as the "model" part of the MVC pattern). The problem is that it is insufficient to call Control.Invoke() when changing information in f.ex a listbox. We also need to make sure the underlying data to be displayed does not change while the UI thread reads it. And simple synchronization is not enough as this will only give atomic access to a single element, when we need to block the entire array while updating the control.
The best solution I've found until now is to model an UI thread and background threads as two separate processes (implemented as .NET threads) that only communicates through messages and has NO shared memory. The messages are modeled through a homebuild "mailbox" interface. The modeled is inspired by the language Erlang.
I'm looking forward to hear if find something smarter ...
Monday, May 05, 2003 11:43 PM by Roy Osherove

# re: UI Threading *<b>Might</b>* Suck

Hmm. I hear ya. I had a feeling this is just the tip of the iceberg. I was thinking that perhaps a generic class could be created that would handle synchronyzation issues between UI threads and others. I can see it taking in A Thread, A Thread Target (A control? A Delegate?) and another set of options and perhaps shared memory Objects (Through interfaces). Then it would handle the incoming streams of events from each thread, making sure each behaves correctly according to the options specified. I bet there is a pattern in here somewhere that someone has written about But i just don't know about it. MVC seems less relevant here, although i suspect it is part of the solution. Oh well. It's the hard(a.k.a cool) stuff that is the most fun, isn't it? ;)
Tuesday, May 06, 2003 6:06 AM by TrackBack

# Julia Lerman Blog

Julia Lerman Blog
Tuesday, May 06, 2003 6:06 AM by TrackBack

# ISerializable

ISerializable
Tuesday, May 06, 2003 6:06 AM by TrackBack

# ISerializable

ISerializable
Saturday, December 18, 2004 8:13 PM by TrackBack

# Is DoEvents Evil?

It's an old VB developer trick, but it also works quite well in .NET: to present responsive WinForms interfaces, do most of your heavy lifting in the first Paint event, rather than in the Load event. I've seen lots...