UI + Worker Многопоточность

Question

У меня проблемы с выполнением операции поиска в фоновом режиме и отображением результатов для пользователя на переднем плане внутри поля списка.

Программа использует SendMessage для отправки результатов запроса обратно вграфический интерфейс

Когда программа закрыта, графический интерфейс пользователя помечает глобальную (изменчивую) переменную как «завершенную» и использует MsgWaitForMultipleObjects для ожидания на дескрипторе потока, чтобы присоединиться к потоку.

КогдаЯ ломаю программу, вижу тупик: графический интерфейс ожидает завершения фонового потока, тогда как фоновый поток ждет в SendMessage.

Этот тупик все еще возникает, когда я использую 100-ms таймаут для MsgWaitForMultipleObjects и вызов его внутри цикла , с QS_ALLINPUT.Я не могу понять, почему.

Является ли этот дизайн даже правильным?Есть ли лучший способ дождаться завершения потока?
Если нет, то в чем проблема?

Answer 1

Вам нужна схема двойной буферизации, чтобы избежать переполнения очереди сообщений. Выложите это так:

Тема 1 выполняет поиск и использует PostMessage для отправки результатов.

Поток 2 читает очередь сообщений, выборочно удаляет сообщения с результатами поиска и сохраняет их во внутренней очереди на основе памяти, которая может обрабатывать любое количество записей.

Поток 3 считывает результаты из внутренней очереди и отображает их.

Обратите внимание, что вам потребуется API get / put для очереди с защитой мьютекса, чтобы потоки 2 и 3 не наступали друг на друга.

Answer 2

После того, как MsgWaitForMultipleObjects скажет "у вас есть сообщение", вам нужно обработать сообщение.Вы получаете только один шанс - если вам не удастся это сделать (и просто вернуться к началу и снова позвонить MsgWaitForMultipleObjects), сообщение останется необработанным, и вы не получите никаких дальнейших уведомлений.

Answer 3

Это классический шаблон потребитель / производитель .Не используйте потоковую очередь сообщений, используйте собственную синхронизированную очередь, желательно с фиксированным размером.Ваш потребитель (поток пользовательского интерфейса) будет замедлять поиск по требованию.Или же вы можете отфильтровать результаты поиска, адаптируясь к скорости потока пользовательского интерфейса, если обнаружите, что очередь синхронизации слишком велика.