re: 異步IO性能探究 愛上龍卷風(fēng) 2008-05-29 17:04
@拖鞋
不好意思，我當(dāng)時(shí)的代碼找不到了，不過我可以給你一個(gè)參考資料：
http://support.microsoft.com/kb/156932看能不能幫到你。
re: 完成端口(IOCP)編程探討 愛上龍卷風(fēng) 2008-05-29 16:56
@iunknown
關(guān)于你提到的框架，本質(zhì)上是多線線程的。負(fù)責(zé) IO 的線程數(shù)目理論上本來就應(yīng)該是你機(jī)器cpu的個(gè)數(shù)。前提是你保證你的io設(shè)計(jì)是異步執(zhí)行的。
re: IOCP Tips 愛上龍卷風(fēng) 2008-03-12 16:58
"標(biāo)準(zhǔn)做法是永遠(yuǎn)設(shè)置NumberOfConcurrentThreads=0"
這個(gè)應(yīng)該和cpu的數(shù)量相一致，而不是永遠(yuǎn)為0
re: c++晦澀語法背后的故事(二) 愛上龍卷風(fēng) 2008-01-14 21:41
@Composition
再者，如果C++改變了現(xiàn)有的內(nèi)存管理機(jī)制，即我提到的：可以考慮在給win變量分配內(nèi)存空間時(shí)，考慮其所有子類需求，然后分配最大數(shù)量的內(nèi)存空間給win變量。
是可以做到多態(tài)規(guī)則的一致性
re: c++晦澀語法背后的故事(二) 愛上龍卷風(fēng) 2008-01-14 21:39
@Composition
1) 首先,我要論述的是多態(tài)規(guī)則,不是只有C++有。很多面向?qū)ο蟮恼Z言都有的特性。Java, C#, Smalltalk。你不必要局限于C++本身。
2) 其次，你說的，我都贊同，這就是c++的內(nèi)存管理機(jī)制。
3) 基于c++的內(nèi)存管理機(jī)制,推出了現(xiàn)有的C++多態(tài)規(guī)則。
4）我是在討論，C++語法為什么復(fù)雜的背后原因。也就是怎么去更好地理解現(xiàn)行的語法。
re: 異步IO性能探究 愛上龍卷風(fēng) 2008-01-11 22:11
@^Shhh^
沒有。
好像沒什么可比性吧。兩個(gè)的應(yīng)用場(chǎng)合不盡相同。
re: 完成端口(IOCP)編程探討 愛上龍卷風(fēng) 2008-01-11 22:09
@abettor.org
應(yīng)該不是業(yè)務(wù)邏輯層速度很慢的問題，cpu的指令執(zhí)行都是很快的，除非你訪問慢速的IO設(shè)備。
對(duì)于業(yè)務(wù)邏輯層,應(yīng)該提高的是并發(fā)的吞吐量。
re: c++晦澀語法背后的故事(二) 愛上龍卷風(fēng) 2008-01-11 22:04
@Composition
我的論述的前提是：“假設(shè)：c++的函數(shù)動(dòng)態(tài)綁定規(guī)則是一致的“
搞不清楚你的觀點(diǎn)是什么？
re: c++晦澀語法背后的故事(一) 愛上龍卷風(fēng) 2007-11-15 22:11
@foobar
非常感謝foobar對(duì)本文詳盡的解釋。
re: 完成端口(IOCP)編程探討 愛上龍卷風(fēng) 2007-11-11 14:19
@RedFox
你說的收到N 個(gè)關(guān)閉消息，指的是你自己定義的嗎？
不管怎么樣，引用計(jì)數(shù)技術(shù)應(yīng)該能幫到你。
re: 完成端口(IOCP)編程探討 愛上龍卷風(fēng) 2007-10-21 20:17
@小明
對(duì)于你的問題，我同意NULL的解釋
re: 完成端口(IOCP)編程探討 愛上龍卷風(fēng) 2007-10-21 20:15
@RedFox
你應(yīng)該弄錯(cuò)了,的確,如果按照你的說法,就是單線程了,沒有多線程。
當(dāng)然沒有問題。但是，你的performance是沒法保證的，幾乎沒有什么
throughput的。
re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 愛上龍卷風(fēng) 2007-08-17 15:55
@若弱
謝謝你的comments。
至于你提到的livelock的概念，我在網(wǎng)上查了些資料，基本上有兩種定義：
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）活鎖-如果事務(wù)T1封鎖了數(shù)據(jù)R，事務(wù)T2又請(qǐng)求封鎖R，于是T2等待。T3也請(qǐng)求封鎖R，當(dāng)T1釋放了R上的封鎖之后系統(tǒng)首先批準(zhǔn)了T3的請(qǐng)求，T2仍然等待。然后T4又請(qǐng)求封鎖R，當(dāng)T3釋放了R上的封鎖之后系統(tǒng)又批準(zhǔn)了T4的請(qǐng)求，...，T2有可能永遠(yuǎn)等待，這就是活鎖的情形（來自數(shù)據(jù)庫(kù)領(lǐng)域）
對(duì)于這兩種定義,我個(gè)人偏向于第一個(gè)定義：即程序進(jìn)入無止的循環(huán)當(dāng)中，無法結(jié)束。
不過無論哪種方式，都不適合本文的定義，即：既定時(shí)間的內(nèi)的死鎖。
關(guān)于你說的Lock-free機(jī)制,一般來說，有兩種方法：
第一、對(duì)現(xiàn)有的算法改動(dòng)，使用新的Lock-free算法。這種方法比較難于實(shí)現(xiàn)。
最簡(jiǎn)單的莫過于：將臨界互斥區(qū)代碼委托給另外獨(dú)立的線程，使同步的操作變成異步（本文已經(jīng)提到過）。
第二、使用原子操作原語，比如windows平臺(tái)上的互鎖函數(shù)族，如InterlockedCompareExchange。但是他們不能解決事務(wù)的問題。
re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 愛上龍卷風(fēng) 2007-08-13 22:53
@若弱
直接原因是由于加鎖保護(hù)的代碼執(zhí)行時(shí)間長(zhǎng)造成的。
另外，閣下說的ock-free來代理鎖機(jī)制，是什么意思？
re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 愛上龍卷風(fēng) 2007-08-13 22:42
@阿福
我確實(shí)不知道該把這類現(xiàn)象稱為什么,你有什么好主意,給點(diǎn)建設(shè)性的意見!
另外,這里不是在發(fā)表學(xué)術(shù)文章,只是開發(fā)經(jīng)驗(yàn)的總結(jié),OK?
re: socket vs RMI, 選擇？ 愛上龍卷風(fēng) 2007-07-30 22:22
事實(shí)上，當(dāng)你在開發(fā)一個(gè)cs架構(gòu)的應(yīng)用的時(shí)候，的確會(huì)有這樣兩難的選擇，是使用Socket network programming還是RMI，這樣的對(duì)比是有意義的，基于這一點(diǎn)，Socket network programming和RMI是對(duì)同一個(gè)問題的不同技術(shù)解決方案，當(dāng)然有很多的可比性。
re: 面向?qū)ο蠓治龇椒ㄅc算法 愛上龍卷風(fēng) 2007-06-26 22:40
不過在"分解問題"這個(gè)層次上,從思維方式的角度考慮,我們可以用面向?qū)ο蟮乃季S方式,或者算法式的思維方式
re: 面向?qū)ο蠓治龇椒ㄅc算法 愛上龍卷風(fēng) 2007-06-25 23:13
算法本身的定義是：一種循序漸進(jìn)解決問題的過程，一種為在有限步驟內(nèi)解決問題而建立的可重復(fù)應(yīng)用的計(jì)算過程。
如果我們用算法的思維方式來分解問題，會(huì)使我們拘泥于細(xì)節(jié)。
而面向過程，那是方法論上的定義，不是這里所討論的。
更確切地講，這里是討論的是：
面向?qū)ο蟮姆纸夥椒?vs algorithmic 分解方法