Re: Your advice about WorkerThreads vs UI Threads
MrAsm wrote:
Hi,
I would like to do a computation and don't want the GUI to look "dead"
during this computation.
So, I was thinking about worker threads - the computation is done by
worker thread.
So I was studying Joe's essay about worker threads:
http://www.flounder.com/workerthreads.htm
But I also read on his web site about User Interface threads, and I
read that UI threads don't necessarily have user-interface objects:
http://www.flounder.com/uithreads.htm
So I was wondering if, for doing long computations, it is better to
start a Worker thread or a UI thread.
I was thinking about worker thread (also because I thought -
uncorrectly - that UI threads must have user-interface objects), but
Joe's essay about worker threads clearly show that there are several
non-trivial issues to consider with worker thread, on the other side
it seems that the essay about UI threads is simpler.
Thanks for your advice,
MrAsm
What is your thread going to do when it finishes the computation? If it
is simply going to exit then you certainly want a worker thread: K.I.S.S.
The differences between the two types of threads become interesting if
you want the thread to wait for more work and then do its job again.
To do this, a worker thread would consist of an endless loop containing
a call to WaitForMultipleObjects. It suspends in that call until you
set a "go" event that starts it computing again. Fairly simple, but
this doesn't give you a way to give the thread new parameters, and it
can't cope with giving the thread multiple tasks because there is no
queueing mechanism for the "go" event.
A so-called UI thread consists of a message pump and message map. It
suspends in its message loop until you PostThreadMessage to make it "go"
again. This is a pretty flexible architecture because you can post
new parameters with each message, and the system will queue multiple
such "go" messages to the thread.
--
Scott McPhillips [VC++ MVP]