我正在研究多线程中间件环境。该框架基本上是一个捕获和流式框架。所以它涉及许多线程。
简要介绍一下线程架构：
解复用程序， receiveVideo ， DecodeVideo ， DisplayVideo 等单独的线程。每个线程执行其功能，例如：
解复用器提取音频，视频包
receivevideo 接收视频数据包的标头+有效负载＆amp;删除有效负载
DecodeVideo 接收有效负载＆amp;解码有效载荷包
DisplayVideo 接收已解码的数据包＆amp;显示解码后的数据包
因此，每个线程将提取的数据提供给下一个线程。线程在它们之间共享数据缓冲区，并通过使用互斥锁和信号量来同步缓冲区。同样，还有其他线程可以处理 ananlogvideo 和 analogaudio 等。
所有线程都是在初始化期间产生的，但是它们仍然在信号量上被阻塞，并且根据输入（模拟/数字）选择性信号量被发出信号，以便特定线程被解除阻塞＆amp;继续做他们的工作。在各个阶段，每个线程调用一些较低级别（驱动程序调用）来获取数据或写入数据等。这些调用是阻塞的，并且应该处理这些调用导致的错误（驱动程序返回损坏的数据，驱动程序停止）但当前没有处理
我想实现一个线程监控机制，其中一个线程将监视这些工作线程，如果出现错误情况，将采取一些预防措施。据我所知，某些此类机制通常用于UI或MMI应用程序中的Watchdog。我正在努力寻找类似的东西。
我正在使用pthreads和No Boost或STL（它是遗留代码，几乎是程序化的C ++）
关于特定框架或设计模式或开源项目的任何想法，它们做了类似的事情并可能有助于实现我的要求的想法？
答案 0 :(得分：2)
你可以ping线程 - 定期向每个线程发送一条消息，在其通常的输入队列中，与所有其他正常的东西交错，要求它返回其状态？当每个处理程序线程获取消息时，它会加载带有状态stuff的消息 - 自上次ping以来处理的消息数，输入/输出队列的长度，上次驱动程序返回OK，这种统计信息 - 并将其排队回到你的线程监控机制。如果某些线程被卡住，您的TMM将不得不超时回复。
你可以，也许，只需在整个链中发布一条消息，每个线程在不同的字段中添加自己的状态。这意味着只有一次超时，之后您的TMM必须检查该消息，以查看其获得的链路有多远。
还有其他的东西 - 我喜欢在1s计时器上保持屏幕转储的队列长度和缓冲池深度。如果有什么东西，我通常可以大致说出它的位置，（例如，一个池正在清空，一些队列正在增长 - 队列消费者被浪费了。）
RGDS， 马丁
答案 1 :(得分：1)
当你的某个工作线程出现问题时，使用信号系统唤醒监控线程怎么样？您可以使用某种类型的ResetEvent模拟信令。
当您的工作线程发生异常时，您有一些数据结构，您填写有关异常的数据，然后您可以将其传递给您的监视线程。您可以使用事件唤醒监视线程。
然后监控线程可以做你需要做的事情。
我猜你不希望你的监控线程处于活动状态，除非出现问题，对吗？