Linux 线程的良好使用？

我有一套非常昂贵的操作，但几乎都是独立的。其中一些依赖于某些“全球”状态或数据，但都是只读的。我相当肯定，这些操作本身都可以并行完成，但所有的操作都需要在程序经过某一点之前完成

在这里添加多线程的额外工作和危险值得吗，特别是因为主线程无论如何都必须阻塞和等待

---

另一个问题是，这个应用程序很可能同时在Windows和Linux上运行，我不确定是否值得添加使用两种不同线程系统的代码。

好的，第一个问题是：你真的有问题吗

听起来，您当然可以合理地安全高效地并行化此操作，但如果等待操作以串行方式执行实际上不是问题，那么可能就不值得担心了

---

例如，如果这是一个隔夜执行的批处理应用程序，那么可能不值得这么做。但是，如果这是一个面向用户的应用程序，并且用户已经厌倦了等待，那么使用多线程来解决这个问题似乎是值得的。

您所描述的是并发方面的问题，在许多类型的应用程序中非常流行

---

如果没有更多细节，很难说它是否适合您的应用程序。

如果您有多核处理器，那么您可能能够让线程同时运行，并通过并行性获得加速

---

但是，我认为线程的主要用途是允许更容易地编写多个操作逻辑链，特别是当它们涉及到等待外部事件时，如用户输入或I/O完成。

除非您的工作线程是一组没有并行化好处的病态情况，它们并行完成可能比串行完成得更快。因此，这是否值得的问题就变成了一个问题，即节省了多少时间，在上下文中对您来说又值多少钱。如果有一个焦躁不安的用户在等待鼠标点击来做某事，那么10秒中节省5秒是一个有意义的好处。在cron工作中同样可以节省，但没有那么多

---

如果您认为它很有可能对您有用，那么构建一个快速测试版本，并对其进行分析

+1：不要在不需要的地方增加额外的复杂性。线程代码的额外维护可能不值得获得微小的性能提升。过早优化是万恶之源——Donald KnuthThank，谢谢你，但这实际上有点问题，否则我不会问的。我之所以征求意见，是因为线程让我有点害怕，我想知道其他人是否认为在这种情况下使用线程是值得的。至少在我已经完成的基本测试中，线程有一定的好处和一定的速度提高。然而，我很好奇，这是否足以证明创建一个在Win32和Linux上同时使用线程的健壮解决方案是合理的。