工作线程如何与主 UI 线程通信？答案

【问题标题】：How can worker threads communicate with main UI thread?工作线程如何与主 UI 线程通信？
【发布时间】：2013-10-09 06:16:19
【问题描述】：

工作线程与主 UI 线程通信的最佳方式是什么？

总结：我的 C++/MFC 应用程序是基于对话框的。为了进行冗长的计算，主 UI 线程创建了几个工作线程。当工作线程在计算中进行时，它们会将其进度报告给主 UI 线程，然后主 UI 线程会显示进度。

这适用于共享内存中的数字进度值（由工作人员编写，由 UI 读取），但我在处理文本进度消息时遇到问题。我尝试的解决方案经过了多次迭代，但似乎都没有奏效。

我让 UI 线程将指向控件的指针传递给工作人员，工作人员直接更新了 UI。这不是很有效，而且似乎是错误的方法。
我让工作人员使用 SendMessage 向 UI 线程的窗口发送消息。这就陷入了僵局。（在消息被处理之前，SendMessage 不会返回。）
与 (2) 相同，但在 UI 线程的窗口中使用 PostMessage。这工作了一段时间，然后消息丢失了。（PostMessage 立即返回。）进一步调查显示消息队列的配额已超过默认值 10,000。
我增加了消息队列的配额（注册表中的变量 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERPostMessageLimit），但丢失消息的数量没有改变。
我让每个工作线程在 4 KB 缓冲区中缓冲消息，并在缓冲区填满时使用 PostMessage。这失败了，因为 UI 线程从未收到任何消息。当我将缓冲区大小增加到 64 KB 时也是如此。

工作线程以“最低”优先级运行，而 UI 线程以“正常”优先级运行。工作线程正在发送带有类似代码的消息

UIMessage *pUI=new UIMessage; // so it won't go out of scope (main dialog will delete it)
pUI->buffer=traceLineBuffer; pUI->nOutputs=traceN;
BOOL ok=::PostMessage(hWndMainDlg,TraceLineMsg,(WPARAM)pUI, NULL/*lParam*/);

并且 UI 正在接收它们的代码，例如

BEGIN_MESSAGE_MAP(CMainDlg, CDialog)
...
ON_MESSAGE(TraceLineMsg,OnTraceLineMsg)
...
END_MESSAGE_MAP()

LRESULT CMainDlg::OnTraceLineMsg(WPARAM wParam, LPARAM lParam)
{
    UIMessage *pUI=(UIMessage *)wParam;
    char *p=pUI->buffer;
    // PROCESS BUFFER
    delete[] pUI->buffer;
    delete pUI;
    return 0;
}

问题：

在可能会出现数千个文本报告的情况下，员工发布进度报告的首选方式是什么？
为什么不能增加队列中发帖的配额？
为什么主 UI 线程似乎从未收到缓冲区中的消息，即使传输它们的机制与发布单个报告相同？

64 位 Windows 7、Visual Studio 2010、本机 C++/MFC

【问题讨论】：

发布消息是一种方法。但是您是否考虑过大幅降低消息数量？为什么不只每 100 或 1000 条消息更新一次？
您采取的方法是正确的，但是发送足够多的消息以超过队列限制确实没有意义。唯一可能导致无法接收已发布消息的是超出队列限制或主线程被阻塞，例如在 Sleep 或 WaitFor.. 调用中。发布这些消息时，主线程在做什么？您是否还为每条消息分配另一个 traceLineBuffer ？
koodawg：我确实减少了消息的数量，通过在 (5) 中缓冲它们。
ScottMcP-MVP：主线程在 WaitForMultipleObjects 中，直到工作线程完成。也许这就是问题所在。是的，为每条消息分配了一条新消息和缓冲区，从我在 OnTraceLineMsg 中删除它们可以看出。
我应该说 WaitForMultipleObjects 是为了让工作线程完成：WaitForMultipleObjects(nThreadsActive,threadHandles,TRUE/*wait for all*/,INFINITE);

标签： c++ multithreading mfc

【解决方案1】：

WaitForMultipleObjects 调用中的主线程不会处理任何消息，也不会更新控件或其他窗口。解决方案是：不要那样做。

【讨论】：

【解决方案2】：

在 GUI 上发布进度报告的速度要快于用户可以吸收的速度并没有多大意义。当其他线程中有大量活动时，通常使用 GUI 计时器轮询线程中的进度变量，因此每隔 500 毫秒更新一次 GUI 控件。

这是定时器轮询实际上具有优势的极少数情况之一。您可以获得 peridoc 进度报告，而不必担心在 GUI Windows 消息队列中塞满更新。例如，uTorrent 客户端（存在大量网络活动）使用此方案 - 尝试在收到的每个网络协议单元上更新 GUI 下载统计信息肯定会填满 GUI。

您在 (5) 中的缓冲方案应该有效。我经常通过将对象指针加载到 LPARAM 或 WPARAM 中来将大型数据项传输到主 GUI 线程，在工作线程中对它们进行新的处理，并在显示后在 GUI 中将它们删除。您的 (5) 应该有效，并且至少减少了进度数据传输的开销。我只能假设要显示的数据量仍然太大，因此 GUI 线程仍然跟不上:(

【讨论】：

【解决方案3】：

Windows 上的 MFC 工作线程有多种与主线程通信的选项。您拥有标准的线程信号和同步primitives（互斥量、信号量、event），易于使用的PostMessage，以及更高性能的I/O Completion Port 机制。

// syncronization
{
    CSingleLock lock(&sharedCriticalSection,TRUE);
    sharedList.push_back(msg);
}
// other thread(s) are blocked/pending or you send an event or message to signal

// messages
Data* data = new Data(payload);
PostMessage(hWnd, REGISTERED_MESSAGE, 0, (LPARAM)data);
// target window handles message and deletes data 
// if it is not blocked or too slow and the queue overflows

// skipping lots of IO completion port boilerplate and showing the key methods
messagePort = CreateIoCompletionPort(...);
...
GetQueuedCompletionStatus(messagePort,...);
...
PostQueuedCompletionStatus(messagePort,...);

如果您阻塞或忙于等待线程完成，它们都不会完成太多工作或提高您的性能或响应能力。

对您的观察的评论：

不要让工作人员触摸 GUI。
不要在工作线程中使用 SendMessage。
只要 UI 能够跟上并且不被阻塞，PostMessage 就适用于低容量。
如果您认为这需要改变，您应该重新考虑您的解决方案。少发送或使用性能更高的选项。
如果 UI 未被阻止，合并消息可能会有所帮助。

回答您的问题：

重新评估您是否真的需要一次性发送数千条消息。用户每秒需要多少更改？如果您需要全部发送，请查看 I/O 完成端口机制。
我不会尝试，它可能会奏效，除非...
您的主 UI 线程被阻止等待工作人员在 WaitForMultipleObjects 中完成，并且您的工作人员和其他事件在被阻止时生成的队列消息必须超过最大队列消息。

【讨论】：