Herb Sutter的观点
Herb Sutter最近的一篇文章中如是说：“90年代，我们到处跟人叫讲，什么是对象，什么是虚函数，现在我们到处跟人说，什么是主动对象，什么是Future”，他还说，结构编程、面向对象，现在该轮到并发和并行了。
记得在去年，Herb Sutter就写文章预示并发时代的到来，主要是因为CPU的主频将不再会有以前那样的增长速度，而将迎来多核时代。程序将是靠并发来提高运行效率。
JDK 1.5 Concurrent包
在传统的多线程程序中，经常会有：
创建线程
wait\notify
重新发明轮子，例如BlockingQueue、Lock、Semaphore这样的基本工具类。
不恰当的抽象，会导致难以承受的复杂度，代码错误多，常犯死锁、lost notify之类，也很容易导致性能低下。我也有过这样的经历，失败的教训刻骨铭心。
JDK 1.5 util.concurrent包提供了一系列工具类，其中一些类的使用，代表一些观念的转变，更好的抽象，优雅的设计模式，会使多线程程序具有良好的结构。
使
用Excector、ScheduleExecutorService、Future、BlockingQueue等类搭建起来的程序，会使得多线程程序
有很清晰明了的结构。其中的差别，似乎就象以前“非结构化程序设计”到“结构化程序设计”那样的转变，现在我们使用Future等设计模式，起到了同样好
的效果。
结构化程序设计，使用if/else、while、do...while、for、switch等结构，把程序组织的清晰易懂，更容易掌握，更少出错。
Executor、Future、Concurrent Collection等工具类、模式，使得并发程序结构清晰化/模式化，更容易掌握，更少出错，也更高效。
随着多核CPU的普及，摩尔定律逐步失效，并发程序设计将会是程序员要求掌握的基本技巧，就如同现在程序员要求掌握面向对象一样。
有几个文档值得一看的：
javaone的幻灯片
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3423.pdf
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-5807.pdf
Doug Lea的文章
http://gee.cs.oswego.edu/dl/papers/aqs.pdf
上面的文档只能给你一个介绍，最好的办法还是通读一遍JDK 1.5 utilconcurrent包的源码，然后在实践中，改变观念，积累经验。
并发和网络编程
网
络中，存在中心服务器，不同机器的交互，并发和异步是常见行为。网络中的服务器，需要相应大量的并发，这种并发通常会是极端的并发，操作系统提供一些特别
的API，例如select模型，poll，windows的完成端口等等。JDK在1.4之后支持nio，主要也是针对大并发的支持。
C++的框架ACE，提供了跨平台的线程、进程、Future等API，并且提供了Reactor、Proactor等框架，使得能够容易编写跨平台的并发网络服务器。
ACE框架的一个思想就是，使用ACE和模式消除复杂性。这一点和JDK 1.5 concurrent包提供的高级设计模式类的意图是一致的。
在《C++网络编程》卷1和卷2中讲述了一些模式，例如Half Sync/Aysnc vs Leader/Follow模式。这是ACE开发过程中的一些研究成果，我们查找ACE相关资料时，会发现一些关于并发方面的论文。ACE也提供了Future。
我才运用ACE作了一些简单的应用，了解还不够深入，不过觉得JDK concurrent包在并发设计模式方面，比ACE走到更远。
今天，你使用Future了吗？
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/10/556063.html
并发程序设计的领域，有三个牛人
Doug Lea (Java util.concurrent)
Douglas C. Schmidt (ACE、POSA2)
Herb Sutter （C++/CLI concurrent)
Doug Lea
util.concurrent包的作者，JSR166规范的制定。图书著作《Concurrent Programming in Java:
Design Principles and Patterns》。在JDK
1.6的源码中，还看到他修改的代码（例如重写Exchanger，修正N parters时死锁的问题）。随着JDK
1.5、1.6的普及推广，他的思想，他的作品，都将产生极大的影响。
Douglas C. Schmidt
他创造了ACE，一个流行开源跨平台的C++网络框架。他的图书著作：
《C++ Network Programming: Mastering Complexity Using ACE and Patterns》
《C++ Network Programming: Systematic Reuse with ACE and Frameworks》
《Pattern-Oriented Software Architecture: Patterns for Concurrent & Networked Objects》
他的成果：
Leader/Follow模式
ACE Reacotr
ACE Proactor
虽然ACE中也包括Acitve Object、Future等，他的书中也讲述了基于事件/基于任务的模型，但这些并非他的创造。
Douglas C. Schmidt的成果是网络、并发、跨平台。
Douglas C. Schmidt创造辉煌的时刻已经过去了。
Herb Sutter
ISO C++标准委员会主席，微软C++/CLI首席架构师，Exceptional三卷书的作者，目前领导微软的concur
Project。从2005年开始，他一直发表一些预告并发时代来临的文章。2005年，他代表Microsoft参加OOPSLA，主题就是关于C++
/CLI的并发。Herb Sutter是我极为敬仰的牛人！
他的网站：
http://www.gotw.ca/
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/10/556470.html
C++领域的知名人物
Bjarne Stoustrup 一代宗师，发明了C++，并且作了第一个实现，把面向对象技术带入主流，丰功伟业啊。
Herb Sutter 大师 （IOS/ANSI C++标准委员会秘书，目前领导微软的Concur Porject，推动并发进入主流，有成为宗师的潜力）
Andrei Alexandrescu 牛人 （经典著作《Modern C++ Design Generic Programming and Design Patterns Applied》）
Lippman 牛人 （宝刀已老）
Scott Meyers （著名讲师，自吹为C++领域权威，著作为Effetive C++系列）
侯捷 （著名译者，翻译的书质量不错，但他写的书千万别买）
上面的排名分先后.
Herb Sutter
我最佩服的人之一，他写的Exceptional C++系列三卷书，他的网站www.gotw.ca，OOPSLA上的演讲，他在微软的C++/CLI、Concur Projec等，最近两年所写的关于并发的一些列文章，都是非常非常的棒，偶像啊！！
有胡子的照片比较帅一些。
Bjarne Stoustrup
他来过中国，以前的照片是有胡子的，好酷，最近他网站的照片胡子刮干净了，难道是为了显得年轻一些么？
Lippman
很明显，他已经老了。
Scott Meyers
这就那个说自己是C++领域权威的家伙（真的是吗？）
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/11/557511.html
昨天就开始看这个PPT，看了几遍，对并发的前景有了更多的理解。
http://irbseminars.intel-research.net/HerbSutter.pdf可以从他的网站上下载视频版本。
过去30年，主流软件开发一直忽略了并发。但是现在，并发时代要来了，因为我们的新电脑是并发的，软件开发将会迎来巨变。
现在买的电脑，是双核的，明年就会是4核，然后就是8核，16核，32核……，都是之后几年的事情，一切都不遥远！
很多服务器程序准备好了（也不完全是吧），而客户端程序还没有。
算法的时间复杂度改变了
盲人摸象
技术发展史
|
|
出现 |
进入主流 |
|
GUIs |
1973 (Xerox Alto) |
~1984-89 (Mac)
~1990-95 (Win3.x) |
|
Objects |
1967 (Simula) |
~1993-98 (C++, Java) |
|
Garbage Collection |
1958 (Lisp) |
~1995-2000 (Java) |
|
Generic Types |
1967 (Strachey) |
~198x (US DoD, Ada) ~1995-2000 (C++) |
|
Concurrency |
1964 (CDC 6600) |
~2007-12 (est.) |
他的PPT中还讲述了Acitve Object、Future、Atomic之类的，VC提供特别语法支持。这也是老生常谈的咚咚了。
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/12/558078.html
一般来说，Exchanger都是一个Consumer，一个producer，在适当的时候互相交换，这样可以避免锁。
我想到Exchanger N parties的一种用法。如下：
最初N个都是producer，达到一定条件之后，进行交换。根据交换的结果重新确定角色，决定自己是consumer还是producer。
这样做的结果是，最初所有都是producer，之后一部分转变成consumer。并且由于consumer以及producer的速度不一样，而能够自动适应调整。
要注意的是，JDK 1.5中的Exchanger只支持2 parties，N parties时，N > 2会导致死锁。JDK 1.6中，Exchanger重写了，没有这个问题。
在JDK 1.5中要这样用的话，可以把JDK 1.6中Exchanger源码抄过来就是了。
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/12/558626.html
java.util.concurrent中的ExecutorCompletionService，其实现的是CompletionService接口。
我对ExecutorCompletionService存在一个疑问，在其实现中，task是被执行之后，才把futureTask加入到completionQueue，既然如此，不如直接把Result加入到completionQueue中了。这个行为没什么差别的。对这个类的设计存在一些怀疑，我认为其task方法，似乎返回值是V更合适。
原来是这样的：
Future<V> take() throws InterruptedException;
Future<V> poll();
觉得也许应该改称这样：
V take() throws InterruptedException;
V poll();
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/13/559609.html
客户端程序应用
无意发现的一个类
package javax.swing;
public abstract class SwingWorker<T, V> implements RunnableFuture<T> 
{ }
也就是，一些并发相发的设计模式，已经应用在客户端程序设计中。
我没有对swing关注更多，只是觉得预想中的趋势开始出现了。
Exchanger
重写了，支持N parties。
RunnableFuture
这是理所当然的事情，Executor使用之后，FutureTask这个东西常用，兼有Runnable和Future，所以出现一个RunnableFuture是理所当然。
ConcurrentNavigableMap
一些系列的派生类，例如ConcurrentSkipListMap等等，还没用过，大概就是一个并发支持的SortedMap了。
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/14/559859.html
应该来说，util.concurrent包中提供的atomic，包括两部分：
1、atomic值对象，例如AtomicInteger、AtomicLong等。常用作计数器。
2、AtomicReference
3、一些内部使用Lock提供的compareAndSet操作。例如ConcurrentHashMap的putIfAbsent。
.NET中也提供了类似的功能，InterLocked类提供着完全的能力。
这是一种思想，提供原子操作，把两个以上的操作合并，使得调用者不需要使用Lock，使得程序结构变得简单，减少出错的可能，包括减少死锁发生的可能，程序也因此获得更好的性能。
将会有更多的数据结构支持atomic操作，JDK 1.5提供了支持atomic操作的ConcurrentMap、JDK 1.6提供了支持atomic的ConcurrentNavigableMap。
如同Herb Sutter预测的那样，并发技术将进入主流，这个过程会持续数年。
文章来源:
http://www.cnblogs.com/jobs/archive/2006/11/14/560416.html
原来用不上，只是因为没学好，所以需要重新学习。
文章来源:
http://jobs.cnblogs.com/archive/2006/03/28/360548.html
1、还没有找到快速返回整个BDB Database数据的办法。类似关系数据库中的SELECT * FROM T
2、还没有找到使用索引进行快速分组的办法。类似关系数据库中的SELECT F1, COUNT(*) FROM T GROUP BY F1 HAVING COUNT() > 1
以上的两个问题，我都有了能够正确返回结果的方案，但是还没有快速返回结果的办法。我估计还是需要认真阅读BDB源码之后才能解决。
2006年4月4，我已经找到原来测试返回整个DBD Database数据效率低的原因，是因为使用SerialBinding的原因。全部改成TupleBinding，速度快了很多，速度是SQL Server的三倍。（返回56444行记录）
最近也加入了My SQL的性能测试，事实上My SQL在查询时的速度不如SQL Server。特别作Group by的时候，性能很差的。
文章来源:
http://jobs.cnblogs.com/archive/2006/03/30/362272.html