摘要： 今天在安裝網(wǎng)站的時候遇到了一個 BUG，足足折騰了我三個小時。其現(xiàn)象是網(wǎng)站通過安裝程序部署后，所有的 aspx 頁面均為 404。（1）由于部署環(huán)境是 IIS 6.0，因此第一感覺就像到了是否是禁用了 ASP.NET v2.0 擴展（這也是網(wǎng)上人們對于這個問題的一般回答），但發(fā)現(xiàn)該擴展確實是啟用的；（2）出于狐疑，還是使用 aspnet_regiis –i –enable 重新進行了注冊，但是問題依舊；（3）查看 IIS 日志，發(fā)現(xiàn) 404 是 404.0.0 認定這絕對是路徑的問題而不是 ASP.NET v2.0 擴展或者 Http Handler 映射的問題；（4）經(jīng)過了大眼瞪小眼的查找之 閱讀全文

摘要： 在上一篇中忘記了一個細節(jié)。Range T-K 到底代表了什么？Range T-K Lock 代表了在 SERIALIZABLE 隔離級別中，為了保護范圍內(nèi)的數(shù)據(jù)不被并發(fā)的事務影響而使用的一類鎖模式（避免幻讀）。它由兩個部分構成：第一個部分代表了他鎖定了一個索引范圍，在這個范圍內(nèi)，所有索引使用 T 鎖進行鎖定；第二個部分是而這個范圍內(nèi)已經(jīng)命中的Key，這些 Key 將使用 K 鎖進行鎖定。合并在一起我們說在這個范圍內(nèi)，索引范圍和特定的row的鎖定模式為 Range T-K。舉上一篇的一個例子吧：SELECT [data] FROM [MyTable] WHERE [index_column]&g 閱讀全文

摘要： 在這篇隨筆中，我們的主要關注點在 Key-Range Lock。Key-Range Lock有 S-S、S-U、I-N、X-X幾種情況。我們一個一個來說，力求明白。遺憾的是，這里可能會比較冗長，那么死鎖分析只好依次順延了。Range S-S鎖的獲取規(guī)則MSDN 對 Range 鎖的規(guī)則有部分描述，但是言簡意賅，以下我們會將各種情況分解開來，理清MSDN中涉及的或者未涉及的規(guī)則，這些規(guī)則適用于SQL Server 2000/2005/2008/2008 R2。關于MSDN的描述，請參見：http://technet.microsoft.com/zh-cn/library/ms191272(en- 閱讀全文

摘要： 最近在項目中進行壓力測試遇到了數(shù)據(jù)庫的死鎖問題，簡言之，如下的代碼在 SERIALIZABLE 隔離級別造成了死鎖：SELECT @findCount=COUNT(id) FROM MyTableWHERE [fk_related_id]=@ArgumentIF (@findCount > 0)BEGIN ROLLBACK TRANSACTION RETURN ERROR_CODEENDINSERT INTO MyTable ([fk_related_id],…)VALUES (@Argument,…)COMMIT TRANSACTIONRETURN SUCCESS_CODE在搞清楚這個 閱讀全文

摘要： 有些話，哪一篇博客上也不會說的。可能是因為這些話實在是太愚蠢了，不值得一提，更不可能有人去這樣做。但是我恰恰成為了這個愚蠢的人。這些愚蠢事跡應該好好記錄一下，吃一塹長一智。 今天的話題是，有一個網(wǎng)站，由若干個Application組成，這個網(wǎng)站需要一個登錄服務： （1）每一個人只能夠登錄一次，第二次登錄的人會將第一次登陸人Kick掉； （2）如果這個人已經(jīng)登陸了，需要提示第二次登錄的人是否要繼續(xù)登錄； （3）如果這個人沒有按“注銷”就閃人了（例如關閉了瀏覽器），那么一天之后，這個人會自動被Kick； （4）執(zhí)行該網(wǎng)站的任意操作都將驗證用戶是否已經(jīng)登錄，如果他注銷了，抑或被提出了，那么Kick。 閱讀全文

摘要： 每次在寫 public 方法的時候第一件事就是參數(shù)驗證。以往，都會有這樣的代碼出現(xiàn)：if (oneOfTheArgument == null){ throw new ArgumentNullException( "oneOfTheArgument", StringTable.ErrorClassNameArgNull);}但是方法的參數(shù)表有的時候比較長，邏輯判斷的組合也比較多，此時這種語句的數(shù)目有時多大6-7個。這樣的代碼喧賓奪主，可讀性差（從純數(shù)據(jù)的角度而言，圈復雜度也會比較高）。于是目前全部換成了這種寫法：oneOfTheArgument 是 null 那... 閱讀全文

摘要： 按照上一篇中的計劃，這一篇應當從實踐的角度分析如何在Lock Free Code中注意Out Of Order問題帶來的影響。但是不想這一段時間出了這么多的事情，包括.NET的內(nèi)存模型實現(xiàn)上出了Bug讓人們更加關注這部分的問題。那么這篇就對前幾篇小小隨筆做一個全面的解釋，改正文章里出現(xiàn)的理解錯誤，或容易被理解錯誤的地方。 閱讀全文

摘要： 雖然我們整篇都在討論.NET下的Multi-threading的問題，但是實際上很多問題都是可以類推的。例如前幾次我們反復的說道了關于CriticalSection的問題。說它比MUTEX有何優(yōu)越之處，例如速度就是一個明顯的優(yōu)勢。但是從留言中發(fā)現(xiàn)在這個問題上存在著一些誤會。今天不妨就閑扯一下這個問題。 閱讀全文

摘要： 話說看了Angel Lucifer兄的留言之后，發(fā)現(xiàn)果然Microsoft在June CTP中實現(xiàn)了SemaphoreSlim，其中不但考慮了與舊的同步對象在接口上的一致性，還加入了Cancellation的檢查。唉，怪我沒有跟上形勢！那么這篇就成班門弄斧了。不過，還應該堅持把它寫完，善始善終，就當為大家整理思路。取笑罷了:-) 閱讀全文

摘要： 信號量歷史悠久，折磨死了一代又一代的計算機專業(yè)學生，但是不得不承認其在Multi-thread環(huán)境下的巨大作用。最經(jīng)典的案例莫過于管理一個環(huán)狀緩沖區(qū)。.NET 中的Semaphore對象等同于Win32中的Semaphore。屬于內(nèi)核級對象，因此使用它的代價就比較大了。并且Semaphore對象每次僅僅能夠等待一個Count，這有的時候讓事情變得有些煩，例如你可能不得不將環(huán)狀緩沖區(qū)分割為一個個的Chunk（實際上這是一個好方法，因為我們應該對于Cache進行優(yōu)化）。Qt中的信號量可以一次獲得多個Count，感覺很方便。綜上，我們希望自己動手實現(xiàn)一個輕量級的，支持一次獲得多個資源的信號量。 閱讀全文