0

我有一个 Windows 应用程序需要非常快速地处理所有传入的消息,否则我想它会严重削弱系统性能。我想到的是一种为每条消息生成和加入线程的方法,以便按顺序处理它们。但是这种方法有一个严重的问题:当我产生线程并尝试加入顶级线程时,我怎么知道它是否可用于加入?当然,我可以检查它是否可连接(我使用 std::thread),但是当我这样做时,它可能会变得不可连接并且线程不是互斥锁 - 我不能只是阻止它并再次检查。所以我需要的是某种非阻塞的延迟任务池或任务查询,至少对于消息线程。同样,我可以生成等待该查询的线程并添加任务以便可以处理它,

这不一定是开箱即用的东西,我可以实现任何并发模式。

inb4:Windows、WinAPI、C++11、std::thread 用于线程。对不起我的英语,真的找不到时间改进它。

谢谢你的回答,看来我在问题描述上犯了一个错误。确切地说,我只需要让 WNDPROC 尽快返回它的结果,因此可以从消息队列中弹出下一条消息。我需要这个,因为我记录了发送消息的时间,所以我需要快速完成它,这样它就不会影响时间测量。此外,这些消息对系统来说很紧急,我的窗口需要快速处理它们,否则会以某种方式影响性能。

再次:我需要以某种方式将确切的消息处理移动到其他线程,现在它看起来像这样:


case WM_INPUT:
    int timestamp = PushTimeStampToAsyncTimestampQueue();
    launchLongChainOfMessageProcessing(message,timestamp);
    return 0;

我需要摆脱那个 launchLongChainOfMessageProcessing 并用类似的东西替换它


case WM_INPUT:
    int timestamp = PushTimeStampToAsyncTimestampQueue();
    std::thread processThread([]() { do_work(message, timestamp);});
    return 0;

4

1 回答 1

4

在当前的 Windows 操作系统下,您将发现没有任何方法比使用 I/O 完成端口(简称 IOCP)的重叠 I/O 处理大量入站消息更快、更具可扩展性。它具有令人难以置信的可扩展性和极其通用的功能。

IOCP 允许您定义一个线程池,并让这些线程由 IOCP 子系统管理和调度,等待任何线程上的 IO 完成通知基于 IO 的系统(套接字、管道、文件、任何东西,甚至没有基于 IO 的系统)上的 IO 完成通知,如果您更喜欢;它也构成了一个出色的工作队列分配系统)。

我警告你不要产生线程来处理高度古怪的并发连接。您需要一个稳定的线程池,并且池足够大,这样当一个线程池由于对内核的某些调用(例如等待事件、互斥锁等)的停顿而阻塞时,另一个线程会立即分派工作。产生线程、设置和拆除上下文是昂贵的,所以避免它,幸运的是 IOCP 是一个很好的解决方案。当有工作而其他人忙于其他工作时,它能够让另一个线程从沉睡中醒来,这非常出色。

如果我设置了您所描述的系统(并且给定,您只能通过一些关于 SO 的段落来实现您的最终目标),我会毫不犹豫地使用基于 IOCP 的解决方案。

编辑在 OP 更新了问题之后,我奇怪地会坚持这个答案,但是以一种相当扭曲的方式。他希望它尽可能快地卸载该消息队列的处理。虽然我不会为我的异步传递系统选择 Windows 消息队列,但我相信他有他的理由。

但是,我支持使用基于 IOCP 的系统来进行实际处理。吞吐量和可扩展性简直太好了,不能用于分布式工作系统,而这似乎就是他所拥有的。没有代码,但一般算法会。

  1. 创建一个基于 IOCP 的工作组,所有线程都在等待 GetQueueCompletionStatus()。
  2. 收到每个 WM_INPUT 后,收集您需要的任何参数,构建您的“项目”以进行处理,然后使用 PostQueuedCompletionStatus() 将项目发布到基于 IOCP 的工作人员(顺便说一句,这是埋在工作中最方便的事情-crews“发布”功能)。
  3. 当每个线程被唤醒时,它会交给他们一个工作“项目”来处理。
  4. 处理完一个项目后,池线程返回到 GetQueueCompletionStatus()。

网络上有大量基于 IOCP 的示例工作队列,大多数都可以满足这种需求。除非是由恶魔编写的,否则所有内容都将比您可以在 Windows 下使用的任何其他内容具有出色的性能,因为 IOCP 被紧密集成到计划中。

于 2012-10-01T08:19:21.247 回答