Re: Informing UI thread of target for sending messages?
"L.Allan" <lynn.d.allan@placeholder.gmail.com> wrote in message
news:eyWSM7uUIHA.4584@TK2MSFTNGP03.phx.gbl...
I'm wrestling with a MFC SDI app that will use CWinThread derived user
interface threads to accomplish "scaling" of multi-core cpu's.
A main function of the app is to search files for certain "matches". This
is the "bottleneck" of the app. The nature of the search allows the buffer
holding the 4-5 MB file to be split into multiple parts and searched
independently. For purposes of discussion, I'm looking at splitting the
buffer into 4 parts to fully use a quad-core such as a Q6x00. (eventually
I'll generalize to n-core's ... maybe)
I've got a non-CObject class called CMyFileContents. CMyDoc calls methods
in it to open the file, read it into memory, and do Finds.
At this point, my approach is to have a member function of CMyFileContents
create four user interface threads, and pass offsets and lengths of the
memory buffer with the CMyUiThread constructor. During a find, something
like a loop of
for (i = 0; i < THREAD_COUNT; ++i) {
m_paThread[i]->PostThreadMessage(UWM_START_FIND, wp, lp);
}
will be used to "trigger" the search. The CMyView class will eventually
"organize" the results in a CListCtrl owner data control.
My (limited) understanding of the message pump mechanism is that I will
have each of the ui threads use something like:
::SendMessage(m_hWndFrame,
UWM_THREAD_FIND_DONE,
foundCount, 0);
to inform "somebody" when they are individually done. "Somebody" will know
that 4 threads are involved, so a count-down will figure out when all
threads are done.
My understanding is that typically the CMainFrame class is the
normal/default recipient of user messages in a SDI app.
I've gotten the basic approach to work, but by violating data-hiding /
de-coupling principals by directly informing each of the threads of the
m_hWnd of the CMainFrame. The trying-to-be-more-of-a-purist in me suspects
this is a "hold your nose" approach <g>.
I would greatly appreciate pointers on a preferred way to do this. Should
CMyFileContents derive from CObject or something like CCmdTarget so it can
be the recipient of messages such as UWM_THREAD_FIND_DONE? It seems like
the UWM_THREADS_ALL_DONE message should get back to the CMyDoc, which is
what holds the memory buffer of the file, and indirectly "kicks-off" the
"Find" when the "Find" button handled by the CMyView is clicked.
Here's how I would do it (and I see there is quite some responses to your
message already, but here goes):
1. When the Find button within CMyView is clicked, the CMyView should
handle that message so it can disable the Find button until the search is
done. It can call something like:
void CMyDocument::Find(HWND hwndNotify, UINT notifyMsg); e.g.
CMyView::OnFindClicked()
{
// Disable Find button
// Start Find
GetDocument()->Find(m_hWnd, UWM_FIND_NOTIFIYMSG); //
UWM_FIND_NOTIFYMSG is defined
}
2. CMyDocument::Find() creates 4 WORKER (not UI ) threads. These threads
don't pump messages or receive commands, they just perform the search.
Use AfxBeginThread(), the one which does not take a CWinThread
parameter, but just the entry point to the thread proc. This takes an
LPARAM which is passed to the thread proc, and this can contain a pointer to
a struct which has the HWND and UINT notification parameters (this is how
the thread knows how to notify that it's done).
3. The worker threads do their work and, before exiting the thead proc
function, PostMessage() to the hwndNotify and the supplied UINT msg that
it's done.
4. When CMyView receives this message, it knows how many outstanding
threads remain and acts accordingly.
You could have better encapuslation by putting the stuff in #2 and #3 into
your CMyFileContents, but for it to work, CMyFileContents needs to derive
from CWnd so that it has a HWND for the worker threads to post to.
-- David