Thread callback handling, best practices?

[Large]

Hi

I have a worker-thread that send a callback WM_APP-message to the parent when finished.

(.... workerthread end...)
::SendMessage(hParent, WM_APP+101, NULL, NULL);
return 0;
}

In the parents messageloop we handle data from worker thread and want to create a new worker thread todo next job:

(.... messageloop in mainprogram ....)
if{message == WM_APP+101)
{
DWORD dwCode;
m_thread.Stop(dwCode); //Deadlock since CThread syncronize?
}

I'm currently using the CThread wrapper: http://www.codeproject.com/KB/threads/cthread.aspx

There much be a common practice to manage such scenario. What would you do, with or withour the CThread implementation?

[Lindley]

If you are waiting for the completion of one thread to start another one, then you might be looking for the thread pool pattern, in which you have a persistent background thread (or threads) and dispatch tasks to it to be processed. This saves you the thread teardown/setup time between each task.

I believe WinAPI has some kind of thread pool interface available, but I'm not familiar with it.

[Eri523]

I believe WinAPI has some kind of thread pool interface available, but I'm not familiar with it.

From what I've read I remember that QueueUserAPC() is an essential Win API function for that purpose. I have never used that myself though, so I can't really tell you more about it.

[Arjay]

See QueueUserWorkItem api in msdn.

[Eri523]

See QueueUserWorkItem api in msdn.

Oops! Mixed them up...

[MikeAThon]

(.... workerthread end...)
::SendMessage(hParent, WM_APP+101, NULL, NULL);
return 0;
}

Try ::PostMessage() instead of ::SendMessage(). SendMessage() is waiting for hParent to send back an LRESULT response, and there is thus a potential for deadlock since hParent kills the thread. PostMessage() doesn't wait; it simply places the message in the message queue for hParent and then continues execution with the next statement (here, return 0;).

Mike

[Large]

MikeAThon:
That was it...
I mixed SendMessage/PostMessage from earlier code.

By adding some criticalsections everything synched great for getting text between threads and main program.

All:
As for the threadpool way todo it; how much do you gain to avoid setup/teardown of threads? (The thread is simple fileoperations)

[Arjay]

As for the threadpool way todo it; how much do you gain to avoid setup/teardown of threads? (The thread is simple fileoperations)

With QueueUserWorkItem, you make one api call and it handles all the thread pooling for you. That means, creating and destroying threads, cleaning up handles, etc.

[Large]

Arjay:
Sure, if I made manage code I'll use QueueUserWorkItem()

For info, I found a great article for the new Threadpool in Vista: http://msdn.microsoft.com/en-us/magazine/cc163327.aspx

I cannot used that case the work is spec-ed to work on WinXP, Vista and W7.

[Arjay]

Arjay:
Sure, if I made manage code I'll use QueueUserWorkItem()

Sure there is a managed ThreadPool.QueueUserWorkItem, but I'm referring to the native C++ api.

http://msdn.microsoft.com/en-us/libr...57(VS.85).aspx