TPL并行编程1——概括

    并行编程看似简单，但是其实要设计一个较完美的解决方案是很复杂的。可能由于神秘的错误，程序并不能如预期那样运行。从今天起，我打算每星期更新一次关于并行编程方面的文章。

    在Net4.0中引入了一种新的编程模型，极大简化了并行编程的难度和工作。后台使用了高效的登山算法等保证效率。此外，NET4.0中还包含调试和分析的工具，方便我们更好的掌握并行编程。

1：任务(Task)

      任务是协同工作的一系列顺序操作，他们共同完成一个更大的操作。我们在构建并行程序时，要确定任务的粒度，这有助于硬件的有效利用。如果选择太小，任务管理的开销占主要，如果太粗，可能会失去并行的机会，因为原本可以使用的内核却被闲置。在一般情况下，我们确定任务时应尽可能的大，但他们之间应该相互独立，并且保证有足够多的任务使内核都忙碌。在调试任务时，可能还需要用到探讨法。要把问题分解为任务，对算法、应用程序的结构要有很好的了解。

2：数据的可扩展共享

      不同任务之间通常需要数据共享。问题是，当一个程序并行运行时，程序的不同部分可能会互相竞争对同一内存位置的数据进行更新。这种行为对整个程序来说是灾难性的。解决办法包括同步线程技术。

      在特定情况下通过阻塞并发线程的执行来实现并发线程的同步，比如：锁、原子级别的"比较并交换"、信号灯等。对于数据共享，第一反应可能是添加锁或者其它机制，但是降低了程序的并发性能。除了影响性能外，可能还会造成死锁等茶几问题。但是在有节制的情况中使用锁等同步方式是合理的，不能以性能名义忽略同步的必要性。程序在正确运行的基础上才可以思索它的性能问题。任何一种同步形式都是顺序形式。解决这种情况可以使用不可修改的可读数据、限制程序对共享变量的依赖、在逻辑中添加新步骤、在适当的地方合并对共享数据的描述等。

3：并行性能的极限

阿姆达定律(Amdahl)------我大IBM吉恩·阿姆达尔在1967年提出的计算机科学中的一个重要定律。

Amdahl定律定义：

加速比=采用改进措施后性能/未采用改进措施前的性能=未采用改进措施前执行某任务时间/采用改进措施后执行某任务的时间n个处理器加速因子。

S=n/[1+(n-1)f]:f为非平行百分比，n越大，S不能超过1/f。看着很牛B的样子，其实一言以蔽之：不管有多少内核，并行程序能获得的最大加速比是(1/顺序处理所花费

的时间，理论上)。它保证了你在使用并行编程时对性能的最大期望值。

4：一些经验

1）：尽量停留在抽象最高层使用结构块或库去做并行。

2）：使用已有的并行，比如iis、数据库中的并行性。

3）：使用API封装并行性，比如尽可能使用TPL/PLinq。

4）：在保证整体架构稳妥的前提上再去思考并行性。

5）：尽可能少使用锁、尽量避免共享数据。如果要用共享数据，可能使用共享队列等API。