Q: Multithreaded MDI application...
Tom Fejes -- tom.fejes@sofkin.ca
Wednesday, December 04, 1996
At 10:44 PM 12/1/96 -0800, Mike replied:
>At 10:37 11/20/96 CST, you wrote:
>> Environment: MFC/VC++ 4.0, WinNT 4.0
>
>> Because of the fact that the information is coming to my app via named
>> pipe or socket, and the fact that there can be several connections
>> running concurrently, I need to make each MDI operate on it's own
>> thread, but I am having trouble with GUI threads.
>
>The description of your problem doesn't make the requirement that you
>say is a "need". In fact, the approach you're suggesting is inefficient
>and questionable.
Agreed.
*snip*
>> If there are other samples that pertain to MDI and GUI threads, please
>> let me know. Any suggestions, help is appreciated.
>
>I'm afraid that MTMDI is a very poor sample. It is so widely misunderstood
>that I think it might be best if would remove it from the product.
The MTPRINT example from your book would be really helpful I think Mike.
At least I think it would be. Any scheduled completion time for that?
The WORDFREQ example on the CD doesn't seem to work (on NT 3.51 anyways).
The multithreading part seems to work, but the results don't. And the
UpdateProgress doesn't work on winNT, but works on 95... keeping
Microsoft true to form.
>If your application needs to do communications stuff, I would strongly suggest
>that you:
>
> 1) use the primary thread of your application for all of your UI, including
> the MDI parent frame and all of the MDI children frames _and_ their
> content views.
>
> 2) spawn a thread with each connection you make. the spawned thread might
> not have a UI, unless it would be convenient to have those threads pop up
> windows that aren't direct participants in the MDI framework.
>
> 3) when a communications thread notices something interesting happening, it
> can communicate that fact back to the user interface thread so the update
> can be relayed to the user.
*snip*
>(3), above, requires a great deal of attention. If you're doing communication
>character by character (or, maybe even datagram by datagram) you'll need to
find a reasonable way for the thread to batch up changes to the state of the
>connection
>before giving them back to the user interface thread. The UI thread should be
>asked to repaint for every fistful of characters, or maybe even only ever line
>of characters. You might want to give serious consideration to letting your
>UI thread poll the communications threads rather than letting the
> communications >threads fire notifications back to your UI thread--that
> might make an automatically scaling application more reasonable than
> pciking some arbitrary high water mark to react to.
With my project, I have a UI thread (the primary thread) that spawns
a second thread. The second thread is started from CMainFrame, giving
it a pointer to the view with a byte counter and button to stop the thread.
The second thread gets data from a piece of hardware (in 4kB chunks).
My code is based on the Appwiz Doc/View model, and I haven't found a
'nice' way of passing that 4k chunk of data to the document, so I can
get it to the views. My solution thus far has been to:
a) second thread stores data in a global variable when it has all 4k,
b) call the view (pointer passed by CMainFrame when thread was created)
function to PostMessage to itself letting it know that data is ready.
c) that message is handled by the primary thread which locks the global
variable, gets the data and puts it in the document.
This seems awkward, but it works. I'd rather just pass the 4k of data
from the secondary thread to the primary without using globals and
handshaking, but I haven't figured out how.
Refering to (3), how exactly would one poll another thread? with semaphores?
And how would you get the data when it was ready?
tom.
-----------------------------------------------------------
Tom Fejes - they're goofing around with my mail server,
so try replying to any of the following if you get
a bounced message:
tom.fejes@sofkin.ca
tfejes@fox.nstn.ca
fejes@crow.ewd.dreo.dnd.ca
Mike Blaszczak -- mikeblas@nwlink.com
Friday, December 06, 1996
At 09:09 12/4/96 -0500, Tom Fejes wrote:
>The MTPRINT example from your book would be really helpful I think Mike.
>At least I think it would be. Any scheduled completion time for that?
I posted it last weekend to my web site, but screwed up in updating the
HTML that would have made it public. I think, as of this past Wednesday,
the code is there.
>The WORDFREQ example on the CD doesn't seem to work (on NT 3.51 anyways).
>The multithreading part seems to work, but the results don't. And the
>UpdateProgress doesn't work on winNT, but works on 95...
It's probably more suitable to report bugs to one of the addresses
in the book than to MFC-L. At any rate, you don't say what you mean
by "doesn't work", so I really can't offer you much.
>keeping Microsoft true to form.
There's no reason to be ugly about it. Your comment is very inappropriate.
>Refering to (3), how exactly would one poll another thread? with
>semaphores? And how would you get the data when it was ready?
I'm actually saying the opposite: the main thread should take care of the
UI. It should sit there and pump messages. Secondary threads should block
and process incoming data and block again. If a secondary thread has data
to give back to the main thread, it should post a thread message and let the
UI thread handle the new data at its liesure.
A parameter to the thread message can be a pointer to the block of data.
Maybe the secondary thread allocates it before posting the message, and maybe
the UI thread deletes it when it's copied the data or when it is done painting.
Or, maybe for efficiency, you need to work up a more complicated architecture.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|