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 分解方法