OO思想里被遗忘数十年前的远见-----一篇经典论文的读后.

OO的发展从语法的变迁,和经验的积累归纳来看可以这么说.但是还没有到发展出新范式的地步.
至于壮大么,这个就没人能看得准了.Ruby,Python这样的作者当初也只不过是为了好玩而已.

第一次听说STM，看起来是个大有前途的，有空一定要研究一下。

Scalability :lock base VS STM
请注意引入compiler以后的结果，优化与否的效果差别非常大.

转一个Ruby STM实现.
http://moonbase.rydia.net/mental/blog/programming/ruby-stm-first-round.html



这就是动态语言无奈的地方.

又找了一个Python实现,
http://peak.telecommunity.com/DevCenter/TrellisSTM

有Commit/Rollback/Abort,就没有Retry.

可以说说这张图的来源吗？可以设计一个算法，使得STM的影响非常小，反之亦然。所以想看看这个测试的上下文。
另外，假设完全不需要共享数据的高并发应用里面，STM还会有正面作用吗？
目前又在做一个高并发的应用，几乎不需要共享数据，CPU已经明显不够用了。
考虑过单线程模式，但是由于不是server side的应用，我觉得event机制不太合适（不能带来效率的提高）。

个比较粗糙(指没有提供具体的实现)的benchmark,但是这是唯一一个涉及编译优化的benchmark.
来源在这里
http://research.microsoft.com/~simonpj/papers/stm/STM-OSCON.pdf
如果你想看详细的Benchmark分析可以看这里
research.microsoft.com/~tharris/drafts/cpwl-submission.pdf



如果在Mutli Core的机器上Single Thread还有意义吗?请注意,不要搞混了Parallelism和Concurrency.两者虽然有一定的相似性,但是Concurrency只是在解决IO问题,对非IO的数据计算是无能为力的.很多做服务器端的朋友的经验其实还是来自于在当初单CPU上如何处理网络IO的归纳之上,以为解决了高并发就实际解决了并行问题.这是不对的,Concurrency是一个Closed problem，而parallelism才是一个Open problem.最近一段时间讨论的很多同步技术,Erlang的Message Passing也好,Haskell的STM也好,都是以Parallelism为讨论对象的而不是Concurrency,对于Concurrency的解决只是一个自然而然的副产品因此在这方面的性能必定是无法超越那些专门为Concurrency设计的技术,但是反过来说像ngnix这样的event driven的机制,在Parallelism上面也是活不了太久的.

哦，我承认我就是你说的那种，把concurrency和parallelism搞混了的人，谢谢指正。
虽然event driven看上去很神奇（10Gbps HTTP proxy!）但是在我的场景里面总觉得别扭，刚才终于意识到这种别扭的感觉是对的。

Parallelism和Concurrency的这个说法只是限于高性能计算这个方面吧。
Concurrency这个词的含义我觉得还是有上下文的，比如CCS(Calculus of Concurrent Systems)/π演算，虽然是在另一个领域上，但是是广义的并发概念。

Concurrency是一个Closed problem,那么最终解决方案是什么呢,有没有综述文章推荐一下?

大哥，人家叫Calculus of Communication System好吧
CCS和π演算，都是针对于Task Driven的并发模型,对与task driven有关的Parallelism有很密切的关系.但是反过来说,Parallelism未必一定就是task driven的,不同的并行问题需要由不同的模型处理.