Dance With Automation

first let’s look at the kb on msdn on how to configure windbg for such purpose:http://support.microsoft.com/kb/824344here list a compact steps from kb above, and will it really solve my problem?:1.Configure the "Image File Execution" options. To do this, use one of the following methods:Cl Read More

环境变迁： 把DC上的CAS卸载并转移到另外一台Exchange Server上之后，Outlook便不能正常打开，会出现如下错误： Cannot open your default e-mail folders. The attempt to log on to Microsoft Exchange has failed. 质问MSDN得到原因如下： 当满足下列条... Read More

http://www.cnblogs.com/mavaL/articles/1908263.html 最近看了一些关于GDI/GDI+/D2D/D3D的东东，看到几篇不错的文章，分享一下。 一： 原文链接 : 2D Drawing APIs in Windows 在 Windows 7 操作系统中，微软花费了很大的力气构建了一套新的 2D 绘图 API。我们称之为 Direct2D... Read More

kb:http://www.symantec.com/business/support/index?page=content&id=TECH125894ProblemV-16-1-10165 "Failover group is not completely offline in cluster" appears when failing over a service group from one node to anotherorV-16-1-10155 "Group ServiceGroupNameSG has agent(s) that failed Read More

紧接上回。 Monitor.Enter究竟有没有自旋，还记得在Monitor.Wait初探系列中我们顺带也分析了Enter对应的代码逻辑嘛？当时通过阅读代码以及windbg调试跟踪两种方式都确认等待锁的线程最终会调用WaitXXXX进入内核态。现在再来回顾那段代码，就是AwareLock类的AwareLock::Enter方法： void AwareLock::Enter(){ CONT... Read More

写下标题，突然发觉有点淫荡了，把旋改成慰，一字之差，效果全然不同，性质也千差万别.淫者见淫，仁者未必仁。本文写作的初衷是探讨lock或者Monitor.Enter的实现是否用到了自旋，也即所谓的spinning。因为网上众多的意见和看法都是lock是C#/NET中关于线程同步的一种轻量级实现，类似于Windows临界区CriticalSection。那麽究竟有多像，像在哪里？由此也激发了一个偷窥者... Read More

PulseAll MSDN:通知所有的等待线程对象状态的更改。 所以可以理解成所有Wait锁对象的线程都将变成就绪状态。而Pulse顾名思义，只能将排在最前面的Wait就绪。 非常简单吧，下的示例可以说明PulseAll的功能，线程1启动之后会进入Wait状态，紧接着线程3获得锁对象但也马上Wait，然后线程3获得锁对象就PulseAll了。 PulseAll的结果就是前面两个Wait得到释... Read More

现在我们再回到最初的示例上来，ThreadProc1和ThreadProc2之间通过lock关键字进行同步，加在在这两个线程上的lock就好比两扇大门，而这两扇门同时只允许打开一扇。我们先在第一个线程中打开了第一扇门，那第二个线程就要在第二扇门外徘徊。而要打开第二扇门就应该等待第一扇门的Monitor.Exit，Exit的调用就好比是关上当前的门，通知另外的门可以打开了。但是现在似乎出了点”意外“。但是现在第一扇门打开之后，突然蹦出个Monitor.Wait,这玩意是个人物，它除了让第一个线程处于阻塞状态，还通知第二扇门可以打开了。这也就是说：并不需要等到第一扇门调用Monitor.Exit, Read More

打开windbg，哦，不对，先把之前的示例程序改一下，如下，我的目的是为了调试获得Monitor.Enter在进入锁对象并等待之的处理逻辑，所以第一个线程率先拥有了锁对象，但是我们看到第一个线程sleep了太长时间（别学我，我只是为了调试Enter方法），从而导致而第二个线程会长时间的进入徘徊等待的状态，重点就是这第二个线程： using System; using System.Colle... Read More

再来加深一下印象，每一个Object实例都维护一个SyncBlock并通过这个玩意来进行线程的同步,所以Monitor.Wait最终走到这个BOOL SyncBlock::Wait(INT32 timeOut, BOOL exitContext)并不足奇。在SyncBlock内部我们维护了一个所有正在等待此同步索引块的线程的队列，那具体是通过什麽来控制的呢，通过阅读SyncBlock::Wait源... Read More