.net 4中的任务并行库很强劲，突然有些感触。回顾了下很久前的知识，与园内朋友分享
一些有用的资源 some useful resources：
msdn 并行博客 ：http://msdn.microsoft.com/zh-cn/concurrency/default(zh-cn).aspx
任务并行库TPL(Task Parallel Library)
很明显，库中有两个核心内容：任务、并行。
并行(Parallel)和并发(Concurrent)
在并行程序设计的语境中，并行和并发是两个不同的概念，不能互换。当提到多个软件线程并行执行的时候，即意味着这些活动线程在不同的硬件资源或者处理单元上同时执行，也就是说多个线程在任何时间点都同时执行。当提到多个软件线程并发执行的时候，即意味着这些线程在同一个硬件资源上交替执行的过程，也就是所有活动线程在某段时间内同时执行的状态，但在某个给定的时刻都只有一个线程在执行。要提高并行性就必须利用多个硬件资源上的并发性。
至此我们几很好理解.NET 4中的几个新集合类型的含义了：
ConcurrentDictionary(Of TKey, TValue)
ConcurrentQueue(Of T)
ConcurrentStack(Of T)
挑战并行思维
“一步接一步”的程序设计模式属线性思维的产物——从程序的一个入口点开始，通过一个任务序列来顺序完成所有工作。具有一定经验的程序员已可以轻松驾驭。这种思维模式相对简单。
要采用并行程序设计模型来设计应用程序，设计人员就必须将自己的思维从上述线性模型中拉出来，重新对整个处理流程进行考虑。程序员应该将应用程序中能够并行执行的部分识别出来，而不是把自己的思维总是限制在串行执行的概念上。要做到这样，程序员必须将应用程序看作是众多相互依赖关系的任务的集合。将应用程序划分成多个独立的任务，并确定这些任务之间的相互依赖的关系的过程就称为分解（decomposition）。分解问题的方式主要有三种：
·任务分解 - 对应用程序根据其执行的功能进行分解的过程称为任务分解。设计的时候常为不同的程序行为采用不同的线程实现，常用于GUI应用程序。
任务分解所针对的目标往往是具有天然可分解性的程序行为。
通俗来说，线程就好比人，而任务分解就是不同人做不同的事。
·数据分解 - 数据分解也称为数据级并行，是将应用程序根据各任务所处理的数据而非按任务的天然特性来进行分解的方法。数据分解常用于对大规模数据量处理。
通俗来讲：多个人做同一件事，每人做一部分
·数据流分解 - 一个线程的输出作为另一个线程的输入，要注意尽量消除启动和排空延迟。
这是典型的生产者/消费者模型。I/O，编译器的设计属于此分解的典型应用。
各种分解方式都具有自身优势。从方便程序设计和任务划分的角度来讲，任务分解方式是最合适的选择。数据分解会给任务增加一些额外的代码复杂性，所以只有在数据容易分解且性能是主要考虑的情况下，数据分解方式才是更加适合的选择。
选择使用怎样的分解方式取决于具体的应用场景，主要应考虑资源问题。相对于传统单线程程序设计而言，并行程序设计更需要以丰富的程序设计经验作为背景，从而对时序和评估作出正确的判断。切记“程序是调出来的”
并行程序设计的挑战
| 同步（Synchronization） | 指两个或多个线程协调其行为的过程。如一个线程停下来等待另一个线程完成某项任务 |
| 通信（Communication） | 指线程之间交换数据相关的贷款和延迟问题 |
| 负载平衡（Load Balancing） | 指多个线程之间工作量分布的情况。负载平衡能够使各线程的工作量平衡均分配。 |
| 可扩展性、伸缩性（Scalability） | 是衡量在性能更加强劲的系统上运行软件时能否有效利用更多线程的指标。例如，若一个应用程序是面向四核系统编写的，那么当程序在八核系统上运行时，其性能能否线性增长（即增加一倍） |
要使应用程序性能达到最优 ，以上问题需要仔细综合考虑。
