CODEWITHSUNDEEP
cmultithreadingwinapibackground-thread
user541686
user541686

Reputation: 210525

UI + Worker Multithreading issue

I'm having trouble performing a search operation in the background, and displaying the results to the user in the foreground inside a list box.

The program uses SendMessage to send the query results back to the GUI.

When the program is closed, the GUI marks a global (volatile) variable as "completed", and uses MsgWaitForMultipleObjects to wait on the thread handle, to join the thread.

When I break the program, I see a deadlock: the GUI is waiting for the background thread to terminate, whereas the background thread is waiting in SendMessage.

This deadlock still occurs when I use a 100-ms timeout for MsgWaitForMultipleObjects and call it inside a loop, with QS_ALLINPUT. I can't figure out why.

Is this design even correct? Is there a better way to wait for the thread to terminate?
If not, what is the issue?

Upvotes: 1

Views: 226

Answers (3)

Raymond Chen
Raymond Chen

Reputation: 45173

After MsgWaitForMultipleObjects says "you have a message" you have to go process the message. You get only one chance - if you fail to do that (and just loop back and call MsgWaitForMultipleObjects again), the message will go unprocessed and you will not receive any further notifications.

Upvotes: 0

Andriy Tylychko
Andriy Tylychko

Reputation: 16266

It's classical consumer/producer pattern. Don't use thread message queue, use your own synchronized queue, preferably fixed-size one. Your consumer (UI thread) will slow down your search thread on demand. Or, alternatively, you can filter search results adapting to UI thread speed if you detect that sync-queue is too large.

Upvotes: 0

Carey Gregory
Carey Gregory

Reputation: 6846

You need a double-buffering scheme to avoid overrunning the message queue. Lay it out like this:

Thread 1 performs the search and uses PostMessage to send results.

Thread 2 reads the message queue, selectively removes search result messages, and stores them in an internal memory-based queue that can handle any number of entries.

Thread 3 reads results from the internal queue and displays them.

Note that you'll need a get/put API for the queue with mutex protection to prevent threads 2 and 3 from stepping on each other.

Upvotes: 1

Related Questions