问题标签 [waitformultipleobjects]

我正在尝试编写一个使用 Win32 API 将 stdin/stdout 映射到串行端口（各种命令行终端仿真器）的小实用程序。我有以下代码，我认为它应该可以工作，但它似乎没有从串口正确接收通知：

有什么想法我在这里做错了吗？

文字问题：

对于我的应用程序，我有一个从串行端口读取的类。它使用 Windows 原语进行 COM 端口处理，并有一个用于异步读取的线程。我正在尝试使用 Boost.Asio 和 Boost.Thread 等 Boost 库将其从 Windows 原语转换。

在 Windows 端口中，我的 IO 线程有几个 MFC CEvent 变量，每个变量代表一条消息：Read requested、Write requested、Read completed、Write completed、IO Cancelled。这些是用 WaitForMultipleObjects 等待的。

我遇到的问题是 Boost.Thread 似乎既没有 CEvent 也没有 WaitForMultipleObjects 的类似物。我最接近的方法是丢弃这些并用一组布尔值替换事件，然后使用条件变量，只要布尔值发生变化，就会调用它的 notify_all() 函数。

然而，boost::condition_variable 与 CEvent 有一个关键的不同：如果 CEvent 在没有被等待时发出信号，那么下一次等待它会立即成功。使用 boost::condition_variable，如果没有等待，任何通知函数都会被忽略。

这意味着在检查标志和等待可能丢失通知的 condition_variable 之间总是存在间隙。这会导致线程挂起。

有人知道这个问题的解决方案吗？

代码中的问题：

如何在 Boost.Thread 中模拟它？

我有一些适用于 Windows 的 C++ 代码，我打算将它移植到 Java。但不幸的是，这并不像我想象的那么容易。有人可以帮我吗？

请看一下算法：

hDataAvailabeEvent 可以从不同的线程中设置。如果所有数据都已处理完毕，则事件重置并在调用 WaitForMultipleObjects 时线程将暂停，直到新数据到达或线程退出时间到来。

我已经在 J​​ava 中看到过Waitformultipleobjects问题，但它不适合我的情况，因为我无法在 1 个循环迭代中处理所有新数据，并且处理分布在一些迭代中。

提前致谢！

基于这个问题，我将使用 Poco::NamedEvent，但我需要等待多个事件（如 win32 WaitForMultipleObjects()

poco有这样的东西吗？（搜索文档并没有产生多少，但也许我没有使用正确的搜索）

我在一个小型 tcp 聊天服务器上写作，但我遇到了一些我无法弄清楚如何“优雅”解决的问题。

下面是我的主循环的代码：它确实：
1. 当建立新的 tcp 连接时，使用标记的基本事件启动一个向量。
2. 获取此连接并将其推回向量中。然后使用套接字创建一个 CSingleConnection 对象并将套接字传递给它。
2.1。从 CSingleConnection 获取事件，该事件在连接接收到数据时被标记...
3. 当它接收到数据时。等待已满并返回数组中句柄的编号...与所有其他向量似乎我可以确定现在正在发送哪个...

但是每个人都可以看到：这种方法真的很差......我无法弄清楚如何更好地完成这一切，获取连接套接字，创建单个连接等等：/...

有什么建议、改进等吗？...

我处理了一些由 WFMO 发出信号的事件，此时它发出了更多 N 次信号。WFMO会返回一次还是N次？

我有一个线程创建需要单线程单元的 COM 对象。

最初，该线程的 main 函数将其放入 WaitForMultipleObjects 循环中。显然这是一个问题，因为它阻止了 COM 消息泵的工作。

我将其替换为 MsgWaitForMultipleObjects 作为解决方案，但现在我遇到了一个问题：MsgWaitForMultipleObjects 有时（经常）返回 WAIT_FAILED，但没有设置错误。

该代码通过继续并尝试再次调用 MsgWaitForMultipleObjects 来处理 WAIT_FAILED 返回值。对 MsgWaitForMultipleObjects 的调用可能会返回 WAIT_FAILED 几次（我见过的最多的是 9 次），但随后它突然可以正常工作了。

编写代码是为了在函数出于正当理由返回 WAIT_FAILED 时可能会进入无限循环。我知道我应该解决这个问题，但目前我认为这是一种“解决方法”，因为 MsgWaitForMultipleObjects 调用最终会成功。

此代码正在 Windows 7、Vista 和 XP（所有 32 位、Windows 7 32 和 64 位）上进行测试。

有谁知道为什么会这样？

相关代码：

示例输出为：

我相信 WAIT_FAILED 返回值仅在等待被消息打破后才会发生。

我有一个创建 10 多个线程的 Windows 服务：

• 做他们的工作，然后进入 WaitForMultipleObjects 状态，直到他们再次恢复..
• 每个线程在其 AppServer 上创建 TDCOMConnection 组件调用方法，然后关闭连接

该服务运行良好，但是我看到了内存泄漏问题。

我只是好奇这个问题是否与消息泵有关。

我一直认为只有在我使用 com 编组时才应该在 STA 线程中应用消息泵送（在我在两个线程之间有代理的情况下）

但是今天我在某处读到，如果阻止呼叫，我应该处理消息。真的吗？

但是我的应用程序仍然可以正常运行，不会阻止自己...

也许我应该使用：CoWaitForMultipleHandles 而不是：WaitForMultipleObjects？

对这个问题有什么想法吗？

我正在研究使用互斥锁保护全局双精度的示例，但是出现错误-

Lab7.exe 中 0x77b6308e 处的未处理异常：0xC0000005：访问冲突写入位置 0x00000068。

我认为这与访问分数有关？（全球双标）

更新：

在解决了将循环设置为 1000 而不是 10 的问题后，错误仍然发生，但是当我注释掉引用互斥锁的代码时，错误没有发生。

更新 2

线程按照惯例返回 0（这是漫长的一周！）

我尝试重新添加与互斥锁相关的代码，程序将编译并运行良好（当然除了双精度的竞争条件问题），CRITICAL_SECTION、InitializeCriticalSection 和 DeleteCriticalSection 全部重新添加。问题似乎与 EnterCriticalSection或 LeaveCriticalSection，因为当我添加它们时错误再次发生。

我有一个 HANDLE 列表，由许多不同的 IO 设备控制。之间的（性能）差异是什么：

1. 在所有这些句柄上调用 WaitForMultipleObjects
2. boost::windows::basic_handle 上的 async_read 围绕所有这些句柄

WaitForMultipleObjects O(n) 时间复杂度是否为 n 句柄数量？
您可以以某种方式在 windows::basic_handle 上调用 async_read 对吗？还是这个假设是错误的？
如果我在多个线程中调用同一 IO 设备上的运行，这些线程之间的处理调用是否会平衡？这将是使用 asio 的主要好处。