Informing UI thread of target for sending messages?
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.
I came across some methods related to CWinThread ... GetRoutingFrame,
GetRoutingFrame_, GetRoutingView, GetRoutingView_ that seemed interesting,
but I couldn't find any documentation, and the result was a null pointer.
Huh?
Thanks.