Threaded GUI with C# and .NET 2.0

[Martin]

Hi everyone !

I am looking for a good tutorial/tips/code on the web which will
explain me how to build elegantly a good User Interface using threads
in C# and .NET 2.0.

Thanks !

Martin

 

[Carl Daniel [VC++ MVP]]

Hi everyone !

I am looking for a good tutorial/tips/code on the web which will
explain me how to build elegantly a good User Interface using threads
in C# and .NET 2.0.

First rule: don't use multiple threads.

Second rule: if you have a good reason to use multiple threads, make sure
that exactly 1 of those threads ever touches the UI. With .NET 2.0 in
particular, debug builds will Assert if you try to access the UI from the
wrong thread.

WinForms 2.0 includes a new BackgroundWorker component that's intended to
make it easy to do thread-based work in a GUI. I'd suggest getting familiar
with it as a starting point.

-cd

 

[Francois PIETTE]

I am looking for a good tutorial/tips/code on the web which will

explain me how to build elegantly a good User Interface using threads
in C# and .NET 2.0.

You don't need thread to build a good user interface. All visual components
are almost asynchronous and use events. You need thread to do your lengthy
processing so that the user interface doesn't look frozen.

The best application design is to clearly separate the user interface and
the processing. Encapsulate all your processing in classes which will do any
lengthy blocking operation using threads and use events to signal the end of
work to the caller. In those event handler, don't forget to call
InvokeRequired to know how to update your user interface: you can't access
the user interface from a secondary thread because winform controls are not
thread safe. If you call methods of UI controls, or access properties from a
worker thread, it may seems to work but you'll get unpredictable results in
some cases (race conditions).

 

[Martin]

Thank you for you answers !

If I want to load data from a database, should I use thread ? On a
dual-core CPU, my application will be faster, no ?

Thanks,
Martin

 

[Marc Gravell]

Threads aren't always about /speed/, particularly for this case where you
have a UI thread and a DB thread... most of the time it is waiting on the
network, so CPU power isn't the problem, and more CPU grunt doesn't make any
difference. The advantage is /responsiveness/: if your UI thread is busy
talking to the DB, it can't process its message queue, so the form will
appear dead until it finishes (you know... the hourglass, white space if you
move things over it, etc). With a dedicated UI thread and DB thread, the UI
can keep painting while the DB thread gets data... the user is happier. But
for simple tasks like this, multiple threads on a single CPU/core will be
more than sufficient.

In more intensive tasks (codecs, intensive math, etc) then yes: multiple
CPUs/cores running multiple threads can (almost) linearly scale your actual
performance.

Threading is not to be entered lightly. It is easy to screw up. But once you
"get" it, it is OK. In particular, remember that your DB thread *cannot*
talk to the UI directly - it must ask the UI thread to do it...

Jon Skeet has an excellent article on threads that may help:
http://www.yoda.arachsys.com/csharp/threads/

(or post any *specific* questions to this board)

Marc

 

[Francois PIETTE]

If I want to load data from a database, should I use thread ?

If you have a lengthy SQL request then yes, you should use a thread so that
the user interface stay responsive while the database engine is building
your result set and the network is transfering it.

On a dual-core CPU, my application will be faster, no ?

Probably not because the thread executing the lengthy SQL request will just
wait for the database engine or the nework to return data. This task is a
I/O bound task and having multiple CPU would not enhance performance at all.
Using a thread in that case is only interesting to avoid frozing the user
interface while your application wait for data.

As I said in my previous message, you should really decouple your user
interface from your data processing. Do not messt all. Your code will be
must better and you'll be able to reuse your data processing with another
user interface, for example moving from a winform to a web application or
separating your user interface and data processing in two different machine
to build a multitier application.

Decoupling user interface and data processing will force you to better think
about your application. The end result is a better application. If you work
within a team, you can have someone work on the user interface and another
one work on the data processing.