Re: multithreaded dialog application
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sun, 01 Jul 2007 00:08:55 -0400
See below....
On Fri, 29 Jun 2007 15:34:19 -0000, Ryan <ryan.martino@xxxxxxxxx> wrote:
On Jun 29, 11:08 am, David Wilkinson <no-re...@xxxxxxxxxxxx> wrote:*****
Ryan wrote:
Can anyone give some advice on what possible options I have or if I am
really stuck posting everything to the main thread?
Keep all the GUI in the main thread. What makes you think that your
present arrangement is causing problems?
--
David Wilkinson
Visual C++ MVP
I hypothesize that the high volume of messages, especially from one of
the socket connections, will eventually lead to latency in processing
the messages.
(a) do not preoptimize code until you know there is a problem
(b) the cost of doing the updates is fixed, and will cost the same if done in one thread
or many threads, so there is no saving
******
Since the different message types are by and large*****
processed independently by different child dialogs, there is inherent
parallelization posibilities, especially since the app runs on dual-
core/quad-core machines.
Nothing wrong with computing in parallel. I tend to use I/O Completion Ports as
interthread queues these days, so one solution if you can't do the processing in the
receiving thread is to queue up a computation request to an I/O Completion Port. Then you
can have many service threads that simply retrieve a computation from the queue and figure
out the answer (all threads can compute all results for all computations, for example, and
the struct you are pointing to contains the information that tells the thread what
computation to do), so in a multiprocessor these computations WILL proceed in parallel.
Then all you have to do is update the UI, and that is easy enough now that the
computations are done. Note that one possible solution in the case of multiple updates is
the "write pipe" model, where a thread handles all the updates, let's say to a single
window. Now you get the situation where the update sequece is shown below. Ai is the ith
value of the A control and [Tn] is a time mark for purposes of later discussion.
[T0] A1 B1 C1 D1 A2 B2 A3 A4 A5 B3 B4 A6 A7 [T13] A8 B5 B6 B7 C2 C3 D2 A9 A10 A11
where these are coming in at a rate faster than they can be displayed. the "write pipe"
model works like this:
you write the sequence to the queue in real time.
The queue elements are processed by a thread (e.g., the "Temperature and Humidity Write
Pipe Handler" for the "Temperature and Humidity diaog") It keeps the values in variables,
so that at [T13] the values are
A7 B4 C1 D1
Now you just add an OnTimer handler than every n ms (e.g., n = 250) puts in an "Update
Request" into the queue. Suppose this appears in the queue at time [T13]. At that point,
you PostMessage to the main GUI thread. Note that if data is just being displayed in
controls such as static or edit controls (and, for example, not being plotted) updating
the windows too often makes them flicker and they cannot be read, so this gives a certain
stability to the display. Human perception rates being what they are, "real time"
displays simply cannot be read. Note also that if the write pipe tracks the values it
sent, it would not need to send an update if the current value of A is the same as the
last value of A, thus reducing interthread bandwidth.
joe
*****
*****
Joseph M. Newcomer [MVP]
For the most part, I'm just trying to stay ahead of the curve as far
as message processing capacity goes, but I'm really worried that at
some point the UI performance will degrade with everything going
through the main thread.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Prev by Date: Re: multithreaded dialog application
- Next by Date: Re: multithreaded dialog application
- Previous by thread: Re: multithreaded dialog application
- Next by thread: Re: multithreaded dialog application
- Index(es):
Relevant Pages
|
