服务器端的并行化应用设计似乎已经解决了一些，但仍需要努力提高其扩展能力。
并行化对于客户端的应用是一项巨大的挑战，而对于许多基于服务器的程序来说，却是一个“已经圆满解决的问题”。我们在服务器上使用的并行化架构一直在很好地工作，但要想确保这类架构的顺利编程和扩展能力，人们仍然需要付出巨大的努力。这些应用通常都具有很强的并行特性，它们可以同时处理许多独立的请求流。例如，一台Web服务器或一个Web站点可以独立执行同一代码在大部分不重叠数据上的数千个版本。此外，这些执行都是相互独立的，通过一个抽象数据存储来共享状态，例如通过支持高度并行化访问结构化数据库。今天，表达并行的方式有很多种，每种方式只适用于一个特定的程序子集。这些并行编程模型在两方面的区别比较大:并行运行的粒度和任务间相互配合的程度。
并行执行的操作可能是单个指令，如加法或乘法，也可能是需要用几天时间来运行的复杂程序。很明显，对于小型操作来说，并行基础设施的开销成本是非常巨大的，总的来说，任务分割得越小，将其生成为单个任务和提供通信及同步时所需要的成本就越高。
另外一个方面就是操作间通信和同步配合的程度。最理想的程序是没有任何的配合，操作完全是独立运行的，而且产生的结果也是完全不同的。在这种情况下，操作可以按任何顺序运行，也不会产生任何同步或通信成本，在编程时无须考虑数据竞争的问题，编程过程自然也就会非常容易。然而，这种状态是非常罕见的，多数并行程序都要在操作之间共享数据。当操作变得越来越多样化时，确保正确和有效的操作其复杂性也会随之提高。最简单的案例是为每个操作执行相同的代码，这种共享类型是一种无规律的并行方式。更具有挑战性的是，无规划的并行方式，在这种方式中，操作是完全不同的，而且共享方式也更难以理解。
独立并行 在这种方式下，一种或多种操作是针对数据集中的每个项目独立实施执行的。精细的数据并行依靠的是操作的并行执行，它们不应当共享输入的数据或结果，并应当在无协调的情况下完全可以执行。
在实际应用中，搜索引擎等应用只共享一个大型的只读数据库，因此并发的处理检索不需要任何协调，同样，大型模拟通常需要在运行时分析大量的输入参数，也是一种独立并行模型。
有规律的并行 比独立并行更复杂一些的是当运算之间存在相互依存关系时，将同一种运算应用到一个数据集上。如果两个运算之间存在通信或同步，则在数据上某一部分执行的运算会与另外一个运算存在依存关系。有规律的并行程序要想取得正确的结果，需要同步或认真协调执行策略，与一般并行不同的是，我们可以对这类操作背后的代码进行分析，确定如何以并发的方式对其加以执行，以及确定它们共享哪些数据。
无结构的并行acerun: yes"> 无结构的并行对数据的访问是不可预见的，而且需要通过明确的同步方式对其加以协调。在使用线程和明确的同步方式写成的程序中，这种并行形式最为普遍。在这类程序中每一个线程都有自己特定的职责，我们很难讨论这类并行形式中任何具体的内容，但有一点:两个线程在访问数据时如果发生冲突，就必须使用明确的同步方式来解决，否则，程序将进入无法确定的状态。
网友评论