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?