c++ - 我应该选择什么同步方案来避免实时 C++/MFC 应用程序出现死锁？

Question

我想问你一个问题，关于我应该选择哪种并发工具(CMutex、CSemaphore、CEvent)来制作 C++/MFC 应用程序多线程。

它是一个实时的机器视觉应用程序，现在需要并发执行，并且需要从以前的单线程状态进行重构。

我的工作流程的单次迭代如下。我有 2 个生产者 A、B(MFC Workers)需要填充两个单独的数据结构(每个 1 个)。第三个线程，一个消费者(以及 MFC Worker)被阻塞，直到 A 和 B 的两个数据都变得可用。然后，生产者 A 和 B 必须阻塞(每个，在他们的数据完成时)，C必须唤醒，执行计算，解除阻塞 A 和 B 继续并再次阻塞，等待下一段。

1. 我不能使用队列(类似 Actor)- 阻塞是必需的:(
2. 我尝试了 CEvent，它有效。 A、B 的 AutoResetEvents 以解锁 aCMultiLock 调用 C，然后从 C 调用 ManualResetEvent->Set()，到解锁 A 和 B 等待后一个事件。我关心的是什么时候重置此事件(以防例如 A 错过整个集合然后重置。)
3. 多个 2 的信号量是否代表更好的解决方案？

最好的问候。

Answer 1

C 必须等待两件事发生，所以最合乎逻辑的事情是它等待两个自动重置 CEvent 对象:一个由 A 设置，一个由 B 设置。

当 C 完成后，A 和 B 必须各自等待通知。由于有两个线程，并且都必须唤醒，自然的事情是使用另一对自动重置的 CEvent 对象，一个用于 A 和 B。完成。

计数为 2 的信号量将用于唤醒 C --- C 等待两次，并且 A 和 B 中的每一个通知 --- 但这意味着 C 必须在第一次通知后醒来才能等待第二，不太理想。

之后使用计数为 2 的信号量唤醒 A 和 B 可能会导致被盗唤醒和混淆。 C 向信号量发出两次信号。 A 唤醒并接收信号，进行处理并通知 C，然后再次等待信号量。由于B还没有醒来，信号量还在，所以A又拿走了。同时 B 没有被卡住，因为它不会收到另一个信号，而 C 被卡住，因为它将等待 B 的下一个值。

另一种方法是使用 Windows 条件变量 API 而不是事件，但似乎没有用于此的 MFC 包装器。参见 http://msdn.microsoft.com/en-us/library/ms682052%28VS.85%29.aspx