摘要： 今天在安装网站的时候遇到了一个 BUG，足足折腾了我三个小时。其现象是网站通过安装程序部署后，所有的 aspx 页面均为 404。（1）由于部署环境是 IIS 6.0，因此第一感觉就像到了是否是禁用了 ASP.NET v2.0 扩展（这也是网上人们对于这个问题的一般回答），但发现该扩展确实是启用的；（2）出于狐疑，还是使用 aspnet_regiis –i –enable 重新进行了注册，但是问题依旧；（3）查看 IIS 日志，发现 404 是 404.0.0 认定这绝对是路径的问题而不是 ASP.NET v2.0 扩展或者 Http Handler 映射的问题；（4）经过了大眼瞪小眼的查找之 阅读全文

摘要： 在上一篇中忘记了一个细节。Range T-K 到底代表了什么？Range T-K Lock 代表了在 SERIALIZABLE 隔离级别中，为了保护范围内的数据不被并发的事务影响而使用的一类锁模式（避免幻读）。它由两个部分构成：第一个部分代表了他锁定了一个索引范围，在这个范围内，所有索引使用 T 锁进行锁定；第二个部分是而这个范围内已经命中的Key，这些 Key 将使用 K 锁进行锁定。合并在一起我们说在这个范围内，索引范围和特定的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锁的获取规则MSDN 对 Range 锁的规则有部分描述，但是言简意赅，以下我们会将各种情况分解开来，理清MSDN中涉及的或者未涉及的规则，这些规则适用于SQL Server 2000/2005/2008/2008 R2。关于MSDN的描述，请参见：http://technet.microsoft.com/zh-cn/library/ms191272(en- 阅读全文

摘要： 最近在项目中进行压力测试遇到了数据库的死锁问题，简言之，如下的代码在 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在搞清楚这个 阅读全文

摘要： 有些话，哪一篇博客上也不会说的。可能是因为这些话实在是太愚蠢了，不值得一提，更不可能有人去这样做。但是我恰恰成为了这个愚蠢的人。这些愚蠢事迹应该好好记录一下，吃一堑长一智。 今天的话题是，有一个网站，由若干个Application组成，这个网站需要一个登录服务： （1）每一个人只能够登录一次，第二次登录的人会将第一次登陆人Kick掉； （2）如果这个人已经登陆了，需要提示第二次登录的人是否要继续登录； （3）如果这个人没有按“注销”就闪人了（例如关闭了浏览器），那么一天之后，这个人会自动被Kick； （4）执行该网站的任意操作都将验证用户是否已经登录，如果他注销了，抑或被提出了，那么Kick。 阅读全文

摘要： 每次在写 public 方法的时候第一件事就是参数验证。以往，都会有这样的代码出现：if (oneOfTheArgument == null){ throw new ArgumentNullException( "oneOfTheArgument", StringTable.ErrorClassNameArgNull);}但是方法的参数表有的时候比较长，逻辑判断的组合也比较多，此时这种语句的数目有时多大6-7个。这样的代码喧宾夺主，可读性差（从纯数据的角度而言，圈复杂度也会比较高）。于是目前全部换成了这种写法：oneOfTheArgument 是 null 那... 阅读全文

摘要： 按照上一篇中的计划，这一篇应当从实践的角度分析如何在Lock Free Code中注意Out Of Order问题带来的影响。但是不想这一段时间出了这么多的事情，包括.NET的内存模型实现上出了Bug让人们更加关注这部分的问题。那么这篇就对前几篇小小随笔做一个全面的解释，改正文章里出现的理解错误，或容易被理解错误的地方。 阅读全文

摘要： 虽然我们整篇都在讨论.NET下的Multi-threading的问题，但是实际上很多问题都是可以类推的。例如前几次我们反复的说道了关于CriticalSection的问题。说它比MUTEX有何优越之处，例如速度就是一个明显的优势。但是从留言中发现在这个问题上存在着一些误会。今天不妨就闲扯一下这个问题。 阅读全文

摘要： 话说看了Angel Lucifer兄的留言之后，发现果然Microsoft在June CTP中实现了SemaphoreSlim，其中不但考虑了与旧的同步对象在接口上的一致性，还加入了Cancellation的检查。唉，怪我没有跟上形势！那么这篇就成班门弄斧了。不过，还应该坚持把它写完，善始善终，就当为大家整理思路。取笑罢了:-) 阅读全文

摘要： 信号量历史悠久，折磨死了一代又一代的计算机专业学生，但是不得不承认其在Multi-thread环境下的巨大作用。最经典的案例莫过于管理一个环状缓冲区。.NET 中的Semaphore对象等同于Win32中的Semaphore。属于内核级对象，因此使用它的代价就比较大了。并且Semaphore对象每次仅仅能够等待一个Count，这有的时候让事情变得有些烦，例如你可能不得不将环状缓冲区分割为一个个的Chunk（实际上这是一个好方法，因为我们应该对于Cache进行优化）。Qt中的信号量可以一次获得多个Count，感觉很方便。综上，我们希望自己动手实现一个轻量级的，支持一次获得多个资源的信号量。 阅读全文