我应该了解多线程以及何时使用它，主要是在c ++中

Question

我从未遇到过多线程，但我到处都听说过它。我应该知道什么以及何时使用它？我的代码主要是用c ++编写的。

Answer 1

通常，您需要了解应用程序需要运行的操作系统上的MT库。除非C ++ 0x成为现实（现在看起来很长），否则不支持正确的语言或线程的标准库。我建议你看一下POSIX标准pthreads库，以便开始使用* nix和Windows线程。

Answer 2

这是我的观点，但多线程的最大问题是难度很大。我并不是说从经验丰富的程序员的角度来看，我的意思是它在概念上。一旦你深入并行编程，就会出现很多困难的并发问题。这是众所周知的，并且有许多方法可以使应用程序开发人员更容易实现并发。功能语言因其缺乏副作用和幂等性而变得更受欢迎。一些供应商选择隐藏API背后的并发性（如Apple的Core Animation）。

多头程序可以看到性能方面的巨大进步（用户感知和完成的实际工作量），但您必须花时间来理解代码和数据结构所产生的交互。

Answer 3

MSDN Multithreading for Rookies文章可能值得一读。来自Microsoft，它是根据Microsoft操作系统支持的内容（1993年编辑）编写的，但大多数基本思想同样适用于其他系统，并且具有适当的功能重命名等。

Answer 4

这是巨大的主题。

几点......

• 对于多核，多线程的重要性现在很大。如果您不是多线程，则无法获得该机器的全部性能。
• 多线程 hard 。正确的线程之间的通信和同步是棘手的​​。问题通常是间歇性的，难以诊断，如果设计不适合多线程，很难修复。
• 目前，多线程主要是非便携式和平台特定的。

有一些可移植的库，其中包含有关线程API的包装器。提升是一个。 wxWidgets（主要是GUI库）是另一个。 可以可以合理地移植，但是你不会拥有从特定于平台的API获得的所有选项。

Answer 5

这是一个指向 POSIX threads programming （带图表）的优秀教程的链接，可帮助您入门。虽然本教程是特定于pthread的，但许多概念都转移到其他系统。

要了解有关何时使用线程的更多信息，有助于对并行编程有基本的了解。这是一个关于 parallel computing 基础知识教程的链接，旨在帮助那些刚刚熟悉该主题的人。

Answer 6

我有一个你可能觉得有用的introduction to multithreading。

  

在这篇文章中没有一个   代码行，它不是针对的   教导复杂的   任何给定的多线程编程   编程语言，但给一个   简短介绍，主要关注   关于如何，特别是为什么以及何时   多线程编程将是   是有用的。

Answer 7

其他回复涵盖了如何部分，我将简要提及何时使用多线程。

多线程的主要替代方法是使用计时器。例如，考虑您需要在存在文件的情况下更新表单上的小标签。如果文件存在，则需要绘制特殊图标或其他内容。现在，如果您使用具有低超时的计时器，您可以实现基本相同的功能，该功能可以轮询文件是否存在非常频繁并更新您的ui。没有额外的麻烦。

但是你的功能正在做很多不必要的工作，不是吗。操作系统提供了“嘿此文件已创建”原语，使您的线程处于休眠状态，直到文件准备就绪。显然你不能在ui线程中使用它，否则整个应用程序会冻结，所以你生成一个新线程并将其设置为等待文件创建事件。

现在你的应用程序正在使用尽可能少的cpu，因为线程可以等待事件（无论是使用互斥锁还是事件）。但是说你的文件准备好了。你不能从不同的线程更新你的ui，因为如果2个线程试图同时改变相同的内存位，那么所有的地狱都会破裂。事实上，这是非常糟糕的，以至于windows flat out拒绝你尝试这样做。

所以现在你需要一个同步机制来与ui一个接一个地连接（串行），所以你不要踩到彼此的脚趾，但你不能编写主线程部分，因为ui循环是隐藏在窗户内部。

另一种方法是使用另一种方式在线程之间进行通信。在这种情况下，您可以使用PostMessage将消息发布到找到该文件的主ui循环并完成其工作。

现在，如果你的工作不能等待，并且不能很好地分成小部分（用于短暂超时定时器），你剩下的就是另一个线程以及由此产生的所有同步问题。

这可能是值得的。或者在调试你错过的奇怪竞争条件的几天和几天之后，它可能会让你陷入困境。首先花费很长时间尝试将其分成小块用于计时器可能会有所回报。即使你做不到，只有少数情况会超过时间成本。

Answer 8

你应该知道这很难。有些人认为这是不可能的，没有实际的方法来验证程序是否是线程安全的。 sqlite的作者Hipp博士指出thread are evil.本文详细介绍了problems with threads。

Chrome浏览器使用进程而不是线程，而像Stackless Python这样的工具可以避免硬件支持的线程支持解释器支持的“微线程”。甚至像Web服务器这样的东西，你认为线程将是一个完美的契合，并转向事件驱动的架构。

我自己不会说这是不可能的：很多人都尝试过并且成功了。但毫无疑问，编写生产质量的多线程代码真的很难。成功的多线程应用程序倾向于仅使用几个预定的线程，只需经过一些仔细分析的通信点。例如，只有两个线程的游戏，物理和渲染，或者具有UI线程和后台线程的GUI应用程序，没有别的。在整个代码库中产生并加入线程的程序肯定会有许多不可能发现的间歇性错误。

在C ++中特别难，原​​因有两个：

1. 标准d oesn't mention threads at all的当前版本。所有线程库以及平台和实现都具体。
2. 与Java这样的语言相比，原子操作的范围相当狭窄。
像boost Threads这样的跨平台库可以缓解这种情况。未来的C ++ 0x将引入一些线程支持。但是，boost也有很好的interprocess communication支持，可以用来完全避免线程。

如果您对线程没有任何其他信息，那么它很难并且应该受到尊重，而不是您认识99％以上的程序员。

如果说完毕，你仍然有兴趣开始漫长的艰难道路，能够编写一个不会随机进行段落错误的多线程C ++程序，那么我建议从Boost threads开始。他们有良好的文档记录，高水平，跨平台工作。概念（互斥锁，锁，期货）与所有线程库中存在的几个关键概念相同。