sherrylso

@路人乙
多谢！

@拖鞋
不好意思，我当时的代码找不到了，不过我可以给你一个参考资料：
http://support.microsoft.com/kb/156932
看能不能帮到你。

@iunknown
关于你提到的框架，本质上是多线线程的。负责 IO 的线程数目理论上本来就应该是你机器cpu的个数。前提是你保证你的io设计是异步执行的。

"标准做法是永远设置NumberOfConcurrentThreads=0"
这个应该和cpu的数量相一致，而不是永远为0

@Composition
再者，如果C++改变了现有的内存管理机制，即我提到的：可以考虑在给win变量分配内存空间时，考虑其所有子类需求，然后分配最大数量的内存空间给win变量。
是可以做到多态规则的一致性

@Composition
1) 首先,我要论述的是多态规则,不是只有C++有。很多面向对象的语言都有的特性。Java, C#, Smalltalk。你不必要局限于C++本身。
2) 其次，你说的，我都赞同，这就是c++的内存管理机制。
3) 基于c++的内存管理机制,推出了现有的C++多态规则。
4）我是在讨论，C++语法为什么复杂的背后原因。也就是怎么去更好地理解现行的语法。

@^Shhh^
没有。
好像没什么可比性吧。两个的应用场合不尽相同。

@abettor.org
应该不是业务逻辑层速度很慢的问题，cpu的指令执行都是很快的，除非你访问慢速的IO设备。
对于业务逻辑层,应该提高的是并发的吞吐量。

@Composition
我的论述的前提是：“假设：c++的函数动态绑定规则是一致的“
搞不清楚你的观点是什么？

@foobar
非常感谢foobar对本文详尽的解释。

@RedFox
你说的收到N 個關閉消息，指的是你自己定义的吗？
不管怎么样，引用计数技术应该能帮到你。

@小明
对于你的问题，我同意NULL的解释

@RedFox
你应该弄错了,的确,如果按照你的说法,就是单线程了,没有多线程。
当然没有问题。但是，你的performance是没法保证的，几乎没有什么
throughput的。

@若弱
谢谢你的comments。
至于你提到的livelock的概念，我在网上查了些资料，基本上有两种定义：
1）livelock-An endless loop in program execution. It occurs when a process repeats itself, because it continues to receive erroneous information. It can also occur when a process that calls another process is itself called by that process, and there is no logic to detect this situation and stop the operation. A livelock differs from a "deadlock," in that processing continues to take place, rather than just waiting in an idle loop(From answers).
2）活锁-如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，...，T2有可能永远等待，这就是活锁的情形（来自数据库领域）
对于这两种定义,我个人偏向于第一个定义：即程序进入无止的循环当中，无法结束。
不过无论哪种方式，都不适合本文的定义，即：既定时间的内的死锁。
关于你说的Lock-free机制,一般来说，有两种方法：
第一、对现有的算法改动，使用新的Lock-free算法。这种方法比较难于实现。
最简单的莫过于：将临界互斥区代码委托给另外独立的线程，使同步的操作变成异步（本文已经提到过）。
第二、使用原子操作原语，比如windows平台上的互锁函数族，如InterlockedCompareExchange。但是他们不能解决事务的问题。

@若弱
直接原因是由于加锁保护的代码执行时间长造成的。
另外，阁下说的ock-free来代理锁机制，是什么意思？

@阿福
我确实不知道该把这类现象称为什么,你有什么好主意,给点建设性的意见!
另外,这里不是在发表学术文章,只是开发经验的总结,OK?

事实上，当你在开发一个cs架构的应用的时候，的确会有这样两难的选择，是使用Socket network programming还是RMI，这样的对比是有意义的，基于这一点，Socket network programming和RMI是对同一个问题的不同技术解决方案，当然有很多的可比性。

不过在"分解问题"这个层次上,从思维方式的角度考虑,我们可以用面向对象的思维方式,或者算法式的思维方式

算法本身的定义是：一种循序渐进解决问题的过程，一种为在有限步骤内解决问题而建立的可重复应用的计算过程。
如果我们用算法的思维方式来分解问题，会使我们拘泥于细节。
而面向过程，那是方法论上的定义，不是这里所讨论的。
更确切地讲，这里是讨论的是：
面向对象的分解方法 vs algorithmic 分解方法