UI + Worker Multithreading issue

Question

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?

@AndyT: I don't think so -- the search thread runs faster than the GUI thread, so I would probably overrun whatever buffering of however many messages `PostMessage` does internally. — user541686, Dec 11 '11 at 21:59
Why do you need to wait for the thread to terminate at all? Is there any overriding reason? PostMessage can queue 10000 messages, but you should not get anywhere near that. The easy way to provide flow-control is to create, at startup, a small pool of Objects/Structs/Whatever you use for data transfer, (ie. a producer-consumer queue with the O/S/W pushed on). Your search thread extracts O/S/W from the pool, fills them and PostMessages them off. After processing the messages in the GUI thread, push them back onto the pool. If the search thread tries to overrun, it will get blocked. — Martin James, Dec 11 '11 at 22:43
@MartinJames: Well, when the program is closing I kinda need for it to terminate, haha... — user541686, Dec 11 '11 at 22:51

score 1 · Accepted Answer · answered Dec 11 '11 at 22:06

1

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.

answered Dec 11 '11 at 22:06

Carey Gregory

6,836
2
26
47

How would I (1) notify the thread that it should terminate, and subsequently (2) wait for the thread to terminate, without deadlocking? – user541686 Dec 11 '11 at 22:09
You could use any type of signaling mechanism (eg, a semaphore) to signal the thread to terminate and then simply do a WaitForSingleObject on its thread handle. Since it's using PostMessage rather than SendMessage, there won't be a deadlock created. – Carey Gregory Dec 11 '11 at 22:13
Oh I see... I'm not 100% sure about whether there would be deadlock with `PostMessage`, though, since I didn't expect there to be any deadlock with `SendMessage` either (since I put a timeout, and specified `QS_ALLINPUT`). But it's an idea, thanks. – user541686 Dec 11 '11 at 22:18
@Mehrdad: You should expect deadlock with `SendMessage` because "The SendMessage function calls the window procedure for the specified window and **does not return** until the window procedure has processed the message." – Andriy Tylychko Dec 11 '11 at 22:23
@CareyGregory: no need for 3-threads approach since the same can be done with 2 threads. See my answer. – Andriy Tylychko Dec 11 '11 at 22:37
@AndyT: Huh, I guess for some reason I expected `MsgWaitFor...` to internally process the message by calling the dispatcher. Thanks. – user541686 Dec 11 '11 at 22:38
@AndyT: Both are viable solutions. One requires an extra thread but the other requires somewhat more complex logic and IPC to deal with buffer overrun. The optimal choice would be up to Mehrdad and his app's requirements. – Carey Gregory Dec 11 '11 at 23:23
@CareyGregory: I meant what your thread #2 does can be done in the thread #1. The rest of additional complexity of my answer is applicable to your communication between threads #2 and #3 too. – Andriy Tylychko Dec 12 '11 at 14:43

score 0 · Answer 2 · answered Dec 11 '11 at 22:36

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.

score 0 · Answer 3 · answered Dec 12 '11 at 01:38

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.

UI + Worker Multithreading issue

3 Answers3