0

我正在维护一个多线程并用 C++ 编写的 linux 服务器应用程序。那里大约有 10 个模块和数十个 std::deques 用于消息传递。该应用程序使用生产者-消费者模式在模块之间传递网络数据包。

Producer-Consumer 设计模式在很多情况下都表现良好，但我认为它不适合我们的应用程序。请参阅下面的伪代码中的流聊天：

   CSocketModule (for receiving and sending packets)
   CSockMod::ReceivePackWorkerThread --> CSockMod::Inque -->                    
   CSockMod::InqueWorkerThread --> CSomeMod::Inque -->
   CSomeMod::InqueWorkerThread --> Generates Response Packets -->
   CSomeMod::Outque --> CSomeMod::OutqueWorkThread --> //Optional
   CSockMod::Outque --> CSockMod::SendPackWorkerThread --> 
   Linux Kernel::TCP/UDP Layer

   For each module, there would be two std::deques for buffering 
   in/out pakets, two working threads for processing incoming and 
   outgoing packets respectively.

因为几乎每个 Inque 和 Outque 在运行时都会被两个以上的线程访问，因此必须有很多很多 pthread_mutex_lock 来同步这些队列。但是，这些锁会使应用程序表现得像一个单线程软件。作为服务器应用程序，这不太可能是可接受的。

同时，假设 CSomeMod::Inque 中有 1000 个数据包，第 1000 个数据包是来自客户端的控制数据包，则客户端必须等待 CSomeMod::InqueWorkerThread 处理完 Inque 中的 999 个数据包。控制命令可能会大大延迟！

那么，Producer-Consumer 模式不适合我们的应用吗？还是在这里使用这种模式存在误解？我很感激任何帮助，谢谢！

史蒂夫

4

1 回答 1

0

您可以尝试两件简单的事情来直接解决您的问题：

  1. 将您的 std::deques 加上 pthread_mutexes 替换为单生产者、单消费者无锁队列，如下所示：http ://www.1024cores.net/home/lock-free-algorithms/queues/unbounded-spsc-queue或这个： http: //www.boost.org/doc/libs/1_53_0/boost/lockfree/spsc_queue.hpp
  2. 在需要时为高优先级项目创建额外的队列。始终首先检查这些队列。

您没有提到目前在实践中是否存在任何问题。在任何情况下：个人资料，个人资料，个人资料。

于 2013-06-02T09:31:26.313 回答