实现线程监控机制所需的帮助

发布于 2024-11-04 20:10:44 字数 987 浏览 0 评论 0原文

我正在开发多线程中间件环境。该框架基本上是一个捕获和流媒体框架。所以涉及到很多线程。

给大家简单介绍一下线程架构: 解复用器receiveVideoDecodeVideoDisplayVideo等都有单独的线程。每个线程执行其功能,例如:
解复用器提取音频、视频数据包
receivevideo接收视频数据包的标头+有效负载&删除有效负载
DecodeVideo接收有效负载并进行解码。解码有效负载数据包
DisplayVideo 接收解码后的数据包并发送在显示器上显示解码后的数据包,

因此每个线程将提取的数据提供给下一个线程。线程之间共享数据缓冲区,并且通过使用互斥体和信号量来同步缓冲区。同样,还有其他线程用于处理ananlogvideoanalogaudio等。

所有线程都是在初始化期间生成的,但它们在信号量上保持阻塞状态,并且根据输入(模拟/数字)选择性信号量被发出信号,以便特定线程得到解锁和释放。继续做他们的工作。在各个阶段,每个线程调用一些较低级别(驱动程序调用)来获取数据或写入数据等。这些调用是阻塞的,并且这些调用产生的错误(驱动程序返回损坏的数据、驱动程序停止)应该被处理,但当前尚未处理。

我想实现一个线程监视机制,其中线程将监视这些工作线程,如果发生错误情况将采取一些预防措施。据我了解,某些此类机制通常在 UI 或 MMI 应用程序中使用,例如看门狗。我正在寻找类似的东西。

我正在使用 pthreads 并且没有 Boost 或 STL(它是遗留代码,几乎是过程 C++)

关于特定框架或设计模式或开源项目的任何想法,它们可以做类似的事情,并且可能有助于实现我的要求的想法?

I am working on a multithreaded middleware enviornment. The framework is basically a capturing and streaming framework. So it involves a number of threads.

To give you all a brief idea of the threading architecture:
There are seprate threads for demultiplexer, receiveVideo, DecodeVideo, DisplayVideo etc. Each thread performs its functionlity, for eg:
demultiplexer extracts audio, video packets
receivevideo receives header + payload of video packet & removes payload
DecodeVideo receives payload & decodes payload packet
DisplayVideo receives decoded packets & displays the decoded packets on display

Thus each thread feeds the extracted data to the next thread. The threads share data buffers amongst them and the buffers are synchronised through use of mutexes and semaphores. Similarly, there are other threads for handling ananlogvideo and analogaudio etc.

All the threads are spawned in during initialization but they remain blocked on a semaphore and depending upon the input(analog/digitial) selective semaphores are signalled so that specifc threads get unblocked & move on to do their work. At various stages each thread calls some lower level(driver calls)to get data or write data etc. These calls are blocking and the errors resulting from these calls(driver returning corrupted data, driver stalling) should be handled but are not being handled currently.

I wanted to implement a thread monitoring mechanism where a thread will monitor these worker threads and if an error condition occurs will take some preventive actions. As I understand certain such mechanisms are commonly used like Watchdogs in UI or MMI applications. I am trying to look for something similar.

I am using pthreads and No Boost or STL(its a legacy code, pretty much procedural C++)

Any ideas about specific framework or design patterns or open source projects which do something similar and might help in with ideas for implementing my requirement?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

好听的两个字的网名 2024-11-11 20:10:44

您能否 ping 线程 - 定期在其常用输入队列上向每个线程发送一条消息,与所有其他正常内容交错,要求其返回其状态?当每个处理程序线程获取消息时,它会加载带有状态信息的消息 - 自上次 ping 以来已处理了多少消息、其输入/输出队列的长度、其驱动程序上次返回 OK 的时间以及此类统计信息 - 并将其排队回到你的线程监控机制。如果某些线程被卡住,您的 TMM 必须超时回复。

也许,您可以只在整个链中发布一条消息,每个线程在不同的字段中添加自己的状态。这意味着只有一次超时,之后您的 TMM 必须检查消息以查看它在链中的位置。

还有其他事情 - 我喜欢在 1 秒计时器上保留队列长度和缓冲池深度的屏幕转储。如果有什么东西堵塞了,我通常可以大致知道它在哪里,(例如,一个池正在清空,而一些队列正在增长——队列消费者被浪费了)。

平均值,
马丁

Can you ping the threads - periodically send each one a message on its usual input queue, interleaved with all the other normal stuff, asking it to return its status? When each handler thread gets the message, it loads the message with status stuff - how many messages its processed since the last ping, length of its input/output queue, last time that its driver returned OK, that sort of stats - and queues it back to your Thread Monitoring Mechanism. Your TMM would have to time out the replies in case some thread/s is/are stuck.

You could, maybe, just post one message down the whole chain, each thread adding its own status in different fields. That would mean only one timeout, after which your TMM would have to examine the message to see how far down the chain it got.

There are other things - I like to keep an on-screen dump, on a 1s timer, of the length of queues and depth of buffer pools. If something stuffs, I can usually tell roughly where it is, (eg. a pool is emptying and some queue is growing - the queue comsumer is wasted).

Rgds,
Martin

栀梦 2024-11-11 20:10:44

当您的工作线程之一出现问题时,使用信号系统来唤醒您的监视线程怎么样?您可以使用某种类型的 ResetEvent 来模拟信号发送。

当工作线程中发生异常时,您会使用一些数据结构填充有关异常的数据,然后可以将其传递到监视线程。您可以使用事件唤醒监控线程。

然后监控线程就可以做你需要它做的事情了。

我猜您不希望监控线程处于活动状态,除非出现问题,对吗?

What about using a signalling system to wake up your monitoring thread when something's gone awry in one of your worker threads. You can emulate the signalling with an ResetEvent of some type.

When an exception occurs in your worker thread, you have some data structure you fill up with the data about the exception and then you can pass that on to your monitoring thread. You wake up the monitoring thread by using the event.

Then the monitoring thread can do what you need it to do.

I'm guessing you don't wish to have your monitoring thread active unless something has gone wrong, right?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文