multithreading 什么时候多线程不是一个好主意？

When is multi-threading not a good idea?

提问by CodingWithoutComments

I was recently working on an application that sent and received messages over Ethernet and Serial. I was then tasked to addthe monitoring of DIO discretes. I throught,

我最近正在开发一个通过以太网和串行发送和接收消息的应用程序。然后，我的任务是添加对 DIO 分立器件的监控。我经过，

"No reason to interrupt the main thread which is involved in message processing, I'll just create another threadthat monitors DIO."

“没有理由中断参与消息处理的主线程，我将创建 另一个线程来监视 DIO。”

This decision, however, proved to be poor. Sometimes the main thread would be interrupted between a Send and a Receive serial message. This interruption would disrupt the timing and alas, messages would be lost (forever).

然而，这个决定被证明是糟糕的。有时主线程会在发送和接收串行消息之间中断。这种中断会打乱时间，唉，消息会丢失（永远）。

I found another way to monitor the DIO without using another threadand Ethernet and Serial communication were restored to their correct functionality.

我找到了另一种无需使用其他线程即可监视 DIO 的方法，并且以太网和串行通信已恢复到正确的功能。

The whole fiasco, however, got me thinking. Are their any general guidelines about when notto use multiple-threads and/or does anyone have anymore examples of situations when using multiple-threads is not a good idea?

然而，整个惨败让我开始思考。他们是否有任何关于何时不使用多线程的一般准则和/或当使用多线程不是一个好主意时，是否有人有更多的情况示例？

**EDIT:Based on your comments and after scowering the internet for information, I have composed a blog post entitled When is multi-threading not a good idea?

**编辑：根据您的评论并在互联网上搜索信息后，我撰写了一篇题为多线程何时不是一个好主意的博客文章？

采纳答案by SpoiledTechie.com

1. On a single processor machine and a desktop application, you use multi threads so you don't freeze the app but for nothing else really.
2. On a single processor server and a web based app, no need for multi threading because the web server handles most of it.
3. On a multi-processor machine and desktop app, you are suggested to use multi threads and parallel programming. Make as many threads as there are processors.
4. On a multi-processor server and a web based app, no need again for multi threads because the web server handles it.

1. 在单处理器机器和桌面应用程序上，您使用多线程，因此您不会冻结应用程序，而实际上没有别的。
2. 在单处理器服务器和基于 web 的应用程序上，不需要多线程，因为 web 服务器处理大部分。
3. 在多处理器机器和桌面应用程序上，建议您使用多线程和并行编程。创建与处理器数量一样多的线程。
4. 在多处理器服务器和基于 Web 的应用程序上，不再需要多线程，因为 Web 服务器会处理它。

In total, if you use multiple threads for other than un-freezing desktop apps and any other generic answer, you will make the app slower ifyou have a single core machine due to the threads interrupting each other.

总的来说，如果您将多个线程用于解冻桌面应用程序和任何其他通用答案之外的其他应用程序，那么如果您有一个单核机器，由于线程相互中断，您将使应用程序变慢。

Why? Because of the hardware switches. It takes time for the hardware to switch between threads in total. On a multi-core box, go ahead and use 1 thread for each core and you will greatly see a ramp up.

为什么？因为硬件开关。硬件在线程之间切换总共需要时间。在多核机器上，继续为每个核使用 1 个线程，您会看到明显的提升。

回答by Thomee

To paraphrase an old quote: A programmer had a problem. He thought, "I know, I'll use threads." Now the programmer has two problems. (Often attributed to JWZ, but it seems to predate his use of it talking about regexes.)

套用一句老话：程序员遇到了问题。他想，“我知道，我会用线。” 现在程序员有两个问题。（通常归因于 JWZ，但似乎早于他使用它谈论正则表达式。）

A good rule of thumb is "Don't use threads, unless there's a very compelling reason to use threads." Multiple threads are asking for trouble. Try to find a good way to solve the problem without using multiple threads, and only fall back to using threads if avoiding it is as much trouble as the extra effort to use threads. Also, consider switching to multiple threads if you're running on a multi-core/multi-CPU machine, and performance testing of the single threaded version shows that you needthe performance of the extra cores.

一个好的经验法则是“不要使用线程，除非有非常令人信服的理由使用线程”。多个线程自找麻烦。尝试找到一种不使用多线程的好方法来解决问题，并且只有在避免它与使用线程的额外努力一样麻烦的情况下才回退到使用线程。此外，如果您在多核/多 CPU 机器上运行，请考虑切换到多线程，单线程版本的性能测试表明您需要额外内核的性能。

回答by Adam Liss

Multi-threading is a bad idea if:

在以下情况下，多线程是一个坏主意：

• Several threads access and update the same resource (set a variable, write to a file), and you don't understand thread safety.

• Several threads interact with each other and you don't understand mutexesand similar thread-management tools.

• Your program uses static variables (threads typically share them by default).

• You haven't debugged concurrency issues.

• 多个线程访问和更新同一个资源（设置变量，写入文件），您不了解线程安全。

• 多个线程相互交互，您不了解互斥锁和类似的线程管理工具。

• 您的程序使用静态变量（默认情况下线程通常共享它们）。

• 您还没有调试并发问题。

回答by e-satis

Actually, multi threading is not scalable and is hard to debug, so it should not be used in any case if you can avoid it. There is few cases where it is mandatory : when performance on a multi CPU matters, or when you deal whith a server that have a lot of clients taking a long time to answer.

实际上，多线程是不可扩展的，并且很难调试，所以如果可以避免的话，无论如何都不应该使用它。很少有强制要求的情况：当多 CPU 上的性能很重要时，或者当您处理一个有很多客户端需要很长时间才能回答的服务器时。

In any other cases, you can use alternatives such as queue + cron jobs or else.

在任何其他情况下，您可以使用替代方案，例如队列 + cron 作业或其他。

回答by harningt

You might want to take a look at the Dan Kegel's "The C10K problem" web page about handling multiple data sources/sinks.

您可能需要查看 Dan Kegel 的“ The C10K 问题”网页，了解处理多个数据源/接收器。

Basically it is best to use minimal threads, which in sockets can be done in most OS's w/ some event system (or asynchronously in Windows using IOCP).

基本上最好使用最少的线程，这可以在大多数操作系统中使用一些事件系统（或在 Windows 中使用 IOCP 异步）在套接字中完成。

When you run into the case where the OS and/or libraries do not offer a way to perform communication in a non-blocking manner, it is best to use a thread-pool to handle them while reporting back to the same event loop.

当您遇到操作系统和/或库不提供以非阻塞方式执行通信的方法时，最好使用线程池来处理它们，同时向同一事件循环报告。

Example diagram of layout:

布局示例图：

Per CPU [*] EVENTLOOP   ------ Handles nonblocking I/O using OS/library utilities
                       |                        \___  Threadpool for various blocking events
                       Threadpool for handling the I/O messages that would take long

回答by SingleNegationElimination

Multithreading is bad except in the single case where it is good. This case is

多线程是不好的，除非它是好的单一情况。这个案例是

1. The work is CPU Bound, or parts of it is CPU Bound
2. The work is parallelisable.

1. 工作受 CPU 限制，或部分工作受 CPU 限制
2. 这项工作是可并行的。

If either or both of these conditions are missing, multithreading is not going to be a winning strategy.

如果缺少这两个条件中的一个或两个，多线程将不是一个成功的策略。

If the work is not CPU bound, then you are waiting not on threads to finish work, but rather for some external event, such as network activity, for the process to complete its work. Using threads, there is the additional cost of context switches between threads, The cost of synchronization (mutexes, etc), and the irregularity of thread preemption. The alternative in most common use is asynchronous IO, in which a single thread listens to several io ports, and acts on whichever happens to be ready now, one at a time. If by some chance these slow channels all happen to become ready at the same time, It might seem like you will experience a slow-down, but in practice this is rarely true. The cost of handling each port individually is often comparable or better than the cost of synchronizing state on multiple threads as each channel is emptied.

如果工作不受 CPU 限制，那么您不是在等待线程完成工作，而是在等待某些外部事件（例如网络活动）让进程完成其工作。使用线程，存在线程间上下文切换的额外成本、同步（互斥等）的成本，以及线程抢占的不规则性。最常用的替代方法是异步 IO，其中一个线程侦听多个 io 端口，然后对任何一个现在准备就绪的端口执行操作，一次一个。如果碰巧这些慢速通道都同时准备就绪，您可能会遇到减速，但实际上这很少是真的。当每个通道被清空时，单独处理每个端口的成本通常与在多个线程上同步状态的成本相当或更好。

Many tasks may be compute bound, but still not practical to use a multithreaded approach because the process must synchronise on the entire state. Such a program cannot benefit from multithreading because no work can be performed concurrently. Fortunately, most programs that require enormous amounts of CPU can be parallelized to some level.

许多任务可能受计算限制，但使用多线程方法仍然不切实际，因为进程必须在整个状态上同步。这样的程序不能从多线程中受益，因为不能并发执行任何工作。幸运的是，大多数需要大量 CPU 的程序都可以并行化到某种程度。

回答by Michael Pliskin

Multi-threading is not a good idea if you need to guarantee precise physical timing (like in your example). Other cons include intensive data exchange between threads. I would say multi-threading is good for really parallel tasks if you don't care much about their relative speed/priority/timing.

如果您需要保证精确的物理时间（如您的示例），多线程不是一个好主意。其他缺点包括线程之间的密集数据交换。如果您不太关心它们的相对速度/优先级/时间，我会说多线程对于真正的并行任务很有用。

回答by larsivi

A recent application I wrote that hadto use multithreading (although not unbounded number of threads) was one where I had to communicate in several directions over two protocols, plus monitoring a third resource for changes. Both protocol libraries required a thread to run the respective event loop in, and when those were accounted for, it was easy to create a third loop for the resource monitoring. In addition to the event loop requirements, the messages going through the wires had strict timing requirements, and one loop couldn't be risked blocking the other, something that was further alleviated by using a multicore CPU (SPARC).

我最近编写的一个应用程序必须使用多线程（尽管不是无限数量的线程），我必须通过两个协议在多个方向上进行通信，并监视第三个资源的变化。两个协议库都需要一个线程来运行各自的事件循环，当考虑到这些时，很容易为资源监控创建第三个循环。除了事件循环要求之外，通过线路的消息还有严格的时间要求，一个循环不能冒着阻塞另一个循环的风险，使用多核 CPU (SPARC) 可以进一步缓解这一问题。

There were further discussions on whether each message processing should be considered a job that was given to a thread from a thread pool, but in the end that was an extension that wasn't worth the work.

关于每个消息处理是否应该被视为从线程池中分配给线程的工作，还有进一步的讨论，但最终这是一个不值得工作的扩展。

All-in-all, threads should if possible only be considered when you can partition the work into well defined jobs (or series of jobs) such that the semantics are relatively easy to document and implement, and you can put an upper bound on the number of threads you use and that need to interact. Systems where this is best applied are almost message passing systems.

总而言之，如果可能的话，只有当您可以将工作划分为明确定义的工作（或一系列工作）时才考虑线程，这样语义相对容易记录和实现，并且您可以在您使用的和需要交互的线程数。最适用于这一点的系统几乎是消息传递系统。

回答by Jon Cage

I would say multi-threading is generally used to:

我会说多线程通常用于：

1. Allow data processing in the background while a GUI remains responsive
2. Split very big data analysis onto multiple processing units so that you can get your results quicker.
3. When you're receiving data from some hardware and need something to continuously add it to a buffer while some other element decides what to do with it (write to disk, display on a GUI etc.).

1. 允许在后台处理数据，同时 GUI 保持响应
2. 将非常大的数据分析拆分到多个处理单元，以便您可以更快地获得结果。
3. 当您从某些硬件接收数据并需要一些东西将其连续添加到缓冲区时，而其他元素决定如何处理它（写入磁盘、在 GUI 上显示等）。

So if you're not solving one of those issues, it's unlikely that adding threads will make your life easier. In fact it'll almost certainly make it harder because as others have mentioned; debugging mutithreaded applications is considerably more work than a single threaded solution.

因此，如果您没有解决这些问题之一，那么添加线程不太可能让您的生活更轻松。事实上，它几乎肯定会让它变得更难，因为正如其他人所提到的；调试多线程应用程序比单线程解决方案要多得多。

Security might be a reason to avoid using multiple threads (over multiple processes). See Google chromefor an example of multi-process safety features.

安全性可能是避免使用多线程（在多个进程上）的一个原因。有关多进程安全功能的示例，请参阅Google chrome。

回答by Claus Thomsen

In priciple everytime there is no overhead for the caller to wait in a queue.

原则上每次调用者在队列中等待都没有开销。