Re: Informing UI thread of target for sending messages?
Thanks for the suggestion.
My understanding is that with a non-ui worker thread, you would have them in
a loop waiting for an event to show up (or some other sync object). They
would complete their work, and indicate completion (with a message as you
suggest, or pehaps another event.) I don't think you would want to
create/begin the thread for each search.
I wrestled with the issues some more, and my inclination is now have the
CMyDoc class create the multiple ui-worker threads, and get each search
started with PostThreadMessage's. CMyDoc derives from CCmdTarget, but not
CWnd, so it can't directly get messages back to indicate completion.
My thinking is that the ui-threads would be informed of the "this" of the
CMyDoc, and indicate completion with a plain method call back to
CMyDoc::ThreadDone. This ThreadDone method would use a CCriticalSection to
avoid race conditions.
Something like the following:
void CMyDoc::ThreadDone(int threadIndex, int foundCount)
{
m_criticalSection.Lock();
m_curThreadCountStillWorking--;
m_foundCountOverall += foundCount;
m_foundCountPerThread[threadIndex] = foundCount;
m_criticalSection.Unlock();
if (m_curThreadCountStillWorking == 0) {
... organize results and update view
}
}
This threading newbie would appreciate feedback on whether such an approach
has flaws that I'm overlooking. I can see the potential for incorrect
results and/or hangs if it doesn't work correctly.
I suppose a way to check it would be for a test program have threads that
have very little work to so ... perhaps simply return a known "found count".
All the threads would get done very quickly, and there would be a lot of
contention for the m_criticalSection. With a lot of interations (millions?),
if the m_foundCountOverall was ever wrong or the app hung, that would
indicate a problem.
Not to be prematurely optimizing, but my understanding is that
CRITICAL_SECTIONS aren't kernel objects, and so are relatively "cheap"
compared to messages and events/mutexes/semaphores.
Also, I came across information about InterlockedDecrement,
InterlockedDecrementRelease, and other Interlocked functions. "A little
knowledge is a dangerous thing" ... if the approach above is viable, could
they be used to avoid using the CCriticalSection?
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