服务器诊所：并不是仅仅就是线程化而已

人们普遍对并发—多处理—存有误解。本月的“服务器诊所”要介绍基本的并发概念，为了使您的业务在服务器机柜中安全地进行，您需要这些并发概念。

人们对多处理这个名称存在许多误解。多数理论课程和许多编程教科书都清楚地解释了并发概念，但并发是一个很难的主题，几乎我们所有人都需要进修。

并发指的是一次有不止一个“应用程序”在运行的情形。这里我引用“应用程序”是因为它的意义是依赖于上下文的。Linux主机总是把一组或多或少同时执行的程序（网络协议守护程序、cron管理程序、内核本身，常常还有更多）填到主机的进程表中。Linux是一个多任务的操作系统。它就是为这样的任务而构建的。

在典型的单处理器主机上，任务实际上并不是同时执行的。内核中称为调度程序的部分将工作换进换出，从而让所有工作都获得一轮执行。在同一个时间间隔内，您的浏览器在下载东西，同时您在编辑程序源代码，同时还在播放音乐。并发常常与这种同时出现联系在一起。

并发的两个方面
请记住，从“用户视图”或“编程模型”的角度来看，并发就是关于调度对不可分资源的访问这样一件事情。然而，与之相对的是"后端"意义上的并发。寻求原始性能的人们把重点放在这个不同的方面。在他们看来，“多处理”的意思通常是把单个任务分为几个部分，使不同的中央处理器（centralprocessingunit，CPU）能协同完成任务。其思想是按照外部时钟的步调在更短的时间内完成一项工作，即便要以更复杂的硬件和编程为代价也在所不惜。

并发的这两个方面都与调度，即将任务分配给CPU有关。两者都影响可用性。然而将这两个方面混淆起来却是人们常犯而又棘手的错误。初学编程的人似乎特别容易迷信最重要的并发方法之一—“多线程”。“多线程”常简称为“线程化”，对它的错误印象包括以下一些想法：

线程化使程序运行得更快。
线程化是唯一的并发构造，或者是唯一切实可行的并发构造。
N路主机的速度大约是单处理主机的N倍。
只要对概念作一点点澄清就可以很快地纠正这些错误想法。

天真的开发者常常这样问道，“我的程序太慢了；我可以怎样通过线程化来加快程序的运行？”答案通常是，“办不到。”对现有的单任务应用程序作简单的转换以将它分为几个多任务的部分总是会导致需要更多的计算。一般来说，将这样一个程序“线程化”会使程序要用去更长时间。

这种错误的说法会长久存在，当然有其理由。许多程序都可以分解为几个部分，从而减轻瓶颈问题。将计算密集的工作—比如，对航天飞机重返大气层的模拟—分散给八个CPU而不是一个CPU去做，其完成速度将快得多。更常见的是重构一个程序，以避免输入／输出（input/output，I/O）“阻塞”。如果您的消费者级应用程序能在等待键盘输入、等待从磁盘调入的数据或等待通过网络传来的消息的时候做一些有用的工作，那看起来就像无代价地“提高了速度”似的。

线程化的局限性
但是，相信线程化会带来这些加速是要冒风险的。这些加速都依赖于更深层的分析；仅当存在未充分利用的资源可用的情况下，才有可能提高速度。此外，线程化并不是实现这些并发的唯一办法，并且常常也不是最好的办法。

学术文献研究了至少十二种很重要的投入到了实际应用的并发模型。除听说过线程化外，您多半也听说过多处理（从程序的意义上说）、协同例程和基于事件的编程，也可能听说过连续（continuation）、生成器和几个更神秘难懂的构造。比如，如果您有一种支持生成器但不支持线程的语言，那您可以用生成器来模拟线程（反之亦然），则从这个意义上说，上述所有方法就都有一个形式上大致对等的东西。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有