图书馆设计方法答案

【问题标题】：Library design methodology图书馆设计方法
【发布时间】：2015-11-05 06:10:11
【问题描述】：

我想制作“TRAP AGENT”库。陷阱代理库跟踪客户端系统的各种参数。如果客户端系统的参数更改超过阈值，则客户端的陷阱代理库会通知服务器有关该参数的信息。例如，如果 CPU 使用率超过阈值，则会通知服务器 CPU 使用率已超过。我必须在客户端测量 50-100 个参数（如内存使用情况、网络使用情况等）。现在我对设计有了基本的想法，但我被整个库设计困住了。

我想到了以下解决方案：

我可以为每个参数创建一个线程（即每个线程将监控单个参数）。
我可以为每个参数创建一个进程（即每个进程将监控单个参数）。
我可以将各种参数分为不同的组，比如数据使用参数会归入网络组，CPU内存使用参数会归入系统组，然后为每个组创建线程。

现在第一种解决方案与第二种解决方案相比看起来不错。如果我采用第一种解决方案，那么当我想将库升级为 100 到 1000 个参数时它可能会失败。因为那时我要创建1000个线程，这不是一个好的设计（我认为是这样；如果我错了，请纠正我。）

第三种解决方案很好，但响应时间会很长，因为会在单线程中监控许多参数。

有没有更好的方法？

【问题讨论】：

一千个线程可能比一千个进程好，但也差不了多少。我认为选项 3 听起来更好。您应该计算出每个参数需要多少 CPU 时间（等）。如果您不小心，您将在监控上如此努力地工作系统，以至于无法完成真正的工作。如果您没有过度使用系统（而且您不应该如此），那么选项 3 听起来会更好，而且更好。实际上，您应该能够考虑在单个进程中使用最少数量的线程。
Jonathan Leffler :谢谢..我还可以通过将参数分为两组来最小化线程：紧急参数，非紧急参数。紧急参数需要紧急通知服务器（如系统温度，cpu over时钟等）所以理想情况下我只需要 2 个线程。（考虑到紧急参数很少）

标签： c multithreading optimization shared-libraries static-libraries

【解决方案1】：

一般来说，为代码中的任何逻辑映射生成一对一线程是个坏主意。您可以快速耗尽系统的可用线程。

在 .NET 中，这是使用线程池非常优雅地处理的： Thread vs ThreadPool

这是一个 C++ 讨论，但概念是一样的： Thread pooling in C++11

进程在 Windows 上的开销也很高。具有讽刺意味的是，这两种设计听起来都会对您尝试监控的资源造成很大的负担。

线程（和进程）为您提供所需的并行性。例如，让 GUI 在某些后台任务运行时做出响应。但是，如果您只是在后台监控并向服务器报告，为什么需要这么多的并行性？

您可以在一个单一线程的紧密事件循环中一个接一个地运行每个检查。如果您担心不经常对值进行采样，我会说这实际上是一个好处。消耗 50% 的 CPU 来监控你的 CPU 并没有帮助。如果您每隔几秒对值进行一次抽查，这可能是很好的分辨率。

事实上，如果您要向服务器报告，那么高分辨率是没有帮助的。一旦某个值触发，您不希望通过每秒多次对其进行 HTTP 调用来拒绝服务攻击您的服务器。

注意：这并不意味着您不能拥有可插拔的架构。您可以创建一些表示检查资源的基类，然后为每个特定类型创建子类。您的事件循环可以遍历一个数组或对象列表，依次调用每个对象并聚合结果。在循环结束时，如果有任何超出范围，您会向服务器报告。

一旦陷阱命中，您可能需要添加逻辑来停止检查（或至少停止向服务器报告）一段时间的“冷却期”。您不想对您的服务器征税或向您的日志发送垃圾邮件。

【讨论】：

modal_dialog：是的，你的“创建一个线程”的方法很好，因为我必须在特定的时间间隔内监控所有参数。但是一些参数（我会称之为“紧急参数”）需要紧急通知服务器（如系统温度、cpu 超频等）当时我必须为每个“紧急参数”定义线程。
假设所有检查（即通过循环）足够快地完成，您仍然不需要单独的线程。例如，如果完成所有检查需要 5 秒，这意味着您将在 5 秒内报告高温，这似乎是合理的。我会先在一个循环中构建它（从简单开始），并且仅在花费太长时间时才添加线程。如果出现这种情况，也许有一个低优先级线程和一个高优先级线程。
也没有什么可以阻止您立即报告紧急情况而不是继续其他检查。你仍然不需要另一个线程。我认为您可能高估了获得即时响应的实用性（甚至有用性）。您应该能够在最多几秒的时间范围内一次检查 1,000 个参数。对于单独的服务器可以做的任何响应，这应该是一个很好的解决方案。
modal_dialog：是的，你的回答已经解决了我的大部分问题。但我还必须在熊猫板上移植同一个库，树莓派。那时响应时间会减少吗？因为这些板相当比台式电脑慢，
嗯，这是个好问题，会不会慢一些？我的预感是测试 CPU 使用率、温度等参数不会慢很多。这些东西在所有系统上都比较慢。但是好的设计原则表明你不会因为预期性能问题而使你的设计复杂化，即“过早的优化”stackoverflow.com/questions/385506/…。不过，最好的办法是在您关注的平台上尝试一些简单的原型代码，然后再在开发过程中走得太远。

【解决方案2】：

您可以遵循以下方法：

1.您可以有两个线程，一个线程专用于测量紧急参数，第二个线程监控非紧急参数。因此紧急参数的响应时间会更短。

2.您可以定义3个线程。第一个线程将监控高优先级（紧急参数）。第二个线程将监控中间优先级参数。最后一个线程将监控最低优先级参数。因此，与第一个解决方案相比，整体响应时间将有所改善。

3.如果不关心响应时间，那么您可以在单线程中监控所有参数。但是在这种情况下，当您升级库以监控 100 到 1000 个参数时，响应时间会变得最差。

所以在第一种情况下，非紧急参数的响应时间会更长。而在第三种情况下，响应时间肯定会非常长。所以方案2更好。

【讨论】：