多线程中的lock,Monitor.Wait和Monitor.Pulse
我们知道lock实际上一个语法糖糖，C#编译器实际上把他展开为Monitor.Enter和Monitor.Exit,即：
lock(lockObj)
{
//...
}
////相当于（.Net4以前）：
Monitor.Enter(lockObj);
try
{
//...
}
finally
{
Monitor.Exit(lockObj);
}
但是，这种实现逻辑至少理论上有一个错误：当Monitor.Enter(lockObj);刚刚完成，还没有进入try区的时候，有可能从其他线程发出了Thread.Abort等命令，使得该线程没有机会进入try...finally。也就是说lockObj没有办法得到释放，有可能造成程序死锁。这也是Thread.Abort一般被认为是邪恶的原因之一。
DotNet4开始，增加了Monitor.Enter(object,ref bool)重载。而C#编译器会把lock展开为更安全的Monitor.Enter(object,ref bool)和Monitor.Exit:
lock(lockObj)
{
//...
}
////相当于（DotNet 4）：
bool lockTaken = false;
try
{
Monitor.Enter(lockObj,ref lockTaken);
//
}
finally
{
if (lockTaken) Monitor.Exit(lockObj);
}
现在Monitor.TryEnter在try的保护下，“加锁”成功意味着“放锁”将得到finally的保护。
有一个问题，“Lock关键字不是有获取锁、释放锁的功能吗？...为什么还需要执行Pulse？”
也有朋友有些疑点，“用lock就不要用monitor了”，“Monitor.Wait完全没必要”,“为什么Pulse和Wait方法必须从同步的代码块内调用？”
这些疑问很自然。在大部分情况下，lock确实能基本达到我们要求资源同步的目的，加上配合其他同步工具，比如事件（AutoResetEvent)等的应用,日常工作中确实没有太多机会需要用到Monitor.Wait和Pulse。不过，虽然较少机会用到，事实上Wait和Pulse跟lock完全不是一回事。他们提供了更细腻的同步功能，能达到lock作不来的功能。
为更好的回答和解释这些疑问，该帖将首先介绍Wait和Pulse的用途，通过一个简单例子逐条分析同步的过程；然后提供一个用轻量级的lock,Wait和Pulse来实现一个事件通知的实例；最后谈谈DotNet4对lock编译展开的一点有趣变化。
让我们首先看看MSDN对Monitor.Wait的解释（链接见注释）：
释放对象上的锁并阻止当前线程，直到它重新获取该锁。...
该解释的确很粗糙，很难理解。让我们来看看它下面的备注：
同步的对象包含若干引用，其中包括对当前拥有锁的线程的引用、对就绪队列的引用和对等待队列的引用。
这个多少还给了点东西，现在我们脑海中想像这么一幅图画：
|- 拥有锁的线程
lockObj->|- 就绪队列(ready queue)
|- 等待队列(wait queue)
当一个线程尝试着lock一个同步对象的时候，该线程就在就绪队列中排队。一旦没人拥有该同步对象，就绪队列中的线程就可以占有该同步对象。这也是我们平时最经常用的lock方法。
为了其他的同步目的，占有同步对象的线程也可以暂时放弃同步对象，并把自己流放到等待队列中去。这就是Monitor.Wait。由于该线程放弃了同步对象，其他在就绪队列的排队者就可以进而拥有同步对象。
比起就绪队列来说，在等待队列中排队的线程更像是二等公民：他们不能自动得到同步对象，甚至不能自动升舱到就绪队列。而Monitor.Pulse的作用就是开一次门，使得一个正在等待队列中的线程升舱到就绪队列；相应的Monitor.PulseAll则打开门放所有等待队列中的线程到就绪队列。
比如下面的程序：
static void Main(string[] args) { //设置Priority，确保按代码顺序执行 Thread a = new Thread(A); a.Priority = ThreadPriority.Highest; a.Start(); Thread b = new Thread(B); b.Priority = ThreadPriority.Normal; b.Start(); Thread c = new Thread(C); c.Priority = ThreadPriority.Lowest; c.Start(); Console.ReadLine(); }
static object lockObj = new object(); static void A() { lock (lockObj) //进入就绪队列 { //因为A所在的线程Priority高，所以会先进来 Console.WriteLine("Into A lock block"); Thread.Sleep(1000); //这里调用了Monitor.Pulse(lockObj)，会通知lockObj的等待队列 //但现在lockObj的等待队列没有线程在等待，所以通知不被处理 Monitor.Pulse(lockObj); //自我流放到等待队列 Monitor.Wait(lockObj);//同时此线程在此停止 //线程此时的状态是WaitSleepJoin //虽然在Monitor.Wait之前有Monitor.Pulse通知等待队列，但是过期无效。 //无论之前有多少个Monitor.Pulse //本线程在等待队列后接受到Monitor.Pulse的通知时，线程回到就绪队列 //从就绪队列中出来的时候，线程在此恢复 } Console.WriteLine("A exit..."); } static void B() { lock (lockObj) //进入就绪队列 //B和C都在就绪队列，因为B所在的线程Priority比C高，所以会先进来 Console.WriteLine("Into B lock block"); //这里调用了Monitor.Pulse(lockObj)，会通知lockObj的等待队列 //于此同时，A 已经在等待队列了 Monitor.Pulse(lockObj); Console.WriteLine("B Call Pulse"); } Console.WriteLine("B lock block exit..."); Thread.Sleep(1); Console.WriteLine("B exit..."); } static void C() { //如果CPU是低负载理想的情况，此时的就绪队列中会有两个线程 //除了C还有接收到信号的A，C排在前面理想情况会先进来 但不是绝对，有时会是A lock (lockObj) //进入就绪队列 { Console.WriteLine("Into C lock block"); } Console.WriteLine("C exit..."); }
从时间线上来分析：
T 线程A 0 lock( lockObj ) 1 { 2 //... 线程B 线程C 3 //... lock( lockObj ) lock( lockObj ) 4 //... { { 5 //... //... 6 //... //... 7 Monitor.Pulse //... 8 Monitor.Wait //... 9 //... Monitor.Pulse 10 //... } } 11 }
时间点0，假设线程A先得到了同步对象，它就登记到同步对象lockObj的“拥有者引用”中。
时间点3，线程B和C要求拥有同步对象，他们将在“就绪队列”排队：
|--(拥有锁的线程) A
|
3 lockObj--|--(就绪队列) B,C
|
|--(等待队列)
时间点7，线程A用Pulse发出信号，允许第一个正在"等待队列"中的线程进入到”就绪队列“。但由于就绪队列是空的，什么事也没有发生。
时间点8，线程A用Wait放弃同步对象，并把自己放入"等待队列"。B,C已经在就绪队列中，因此其中的一个得以获得同步对象（假定是B）。B成了同步
对象的拥有者。C现在还是候补委员，可以自动获得空缺。而A则被关在门外，不能自动获得空缺。
|--(拥有锁的线程) B
|
8 lockObj--|--(就绪队列) C
|
|--(等待队列) A
时间点9，线程B用Pulse发出信号开门，第一个被关在门外的A被允许放入到就绪队列，现在C和A都成了候补委员，一旦同步对象空闲，都有机会得它。
|--(拥有锁的线程) B
|
9 lockObj--|--(就绪队列) C,A
|
|--(等待队列)
时间点10，线程B退出Lock区块，同步对象闲置，就绪队列队列中的C或A就可以转正为拥有者（假设C得到了同步对象）。
|--(拥有锁的线程) C
|
10 lockObj--|--(就绪队列) A
|
|--(等待队列)
随后C也退出Lock区块，同步对象闲置，A就重新得到了同步对象，并从Monitor.Wait中返回...
最终的执行结果就是：
B exit...
C exit...
A exit...
顺序不是固定的，而是要结合CPU等系统资源的调配
Pulse和PulseAll方法，这两个方法就是把锁状态将要改变的消息通知给等待队列中的线程，不过这时如果等待队列中没有线程，那么该方法就会一直等待下去，直到有等待的线程进入队列，也就是说该方法可能造成类试死锁的情况出现。
由于Monitor.Wait的暂时放弃和Monitor.Pulse的开门机制，我们可以用Monitor来实现更丰富的同步机制，比如一个事件机(ManualResetEvent):
class MyManualEvent { private object lockObj = new object(); private bool hasSet = false; public void Set() { lock (lockObj) { hasSet = true; Monitor.PulseAll(lockObj); } } public void WaitOne() { lock (lockObj) { while (!hasSet) { Monitor.Wait(lockObj); } } } }
class Program { static MyManualEvent myManualEvent = new MyManualEvent(); static void Main(string[] args) { ThreadPool.QueueUserWorkItem(WorkerThread, "A"); ThreadPool.QueueUserWorkItem(WorkerThread, "B"); Console.WriteLine("Press enter to signal the green light"); Console.ReadLine(); myManualEvent.Set(); ThreadPool.QueueUserWorkItem(WorkerThread, "C"); Console.ReadLine(); } static void WorkerThread(object state) { myManualEvent.WaitOne(); Console.WriteLine("Thread {0} got the green light...", state); } }
我们看到了该玩具MyManualEvent实现了类库中的ManulaResetEvent的功能，但却更加的轻便 - 类库的ManulaResetEvent使用了操作系统内核事件机制，负担比较大（不算竞态时间，ManulaResetEvent是微秒级，而lock是几十纳秒级）。
例子的WaitOne中先在lock的保护下判断是否信号绿灯，如果不是则进入等待。因此可以有多个线程(比如例子中的AB）在等待队列中排队。
当调用Set的时候，在lock的保护下信号转绿，并使用PulseAll开门放狗，将所有排在等待队列中的线程放入就绪队列，A或B（比如A）于是可以重新获得同步对象，从Monitor.Wait退出，并随即退出lock区块，WaitOne返回。随后B或A（比如B）重复相同故事，并从WaitOne返回。
线程C在myManualEvent.Set()后才执行，它在WaitOne中确信信号灯早已转绿，于是可以立刻返回并得以执行随后的命令。
该玩具MyManualEvent可以用在需要等待初始化的场合，比如多个工作线程都必须等到初始化完成后，接到OK信号后才能开工。该玩具MyManualEvent比起ManulaResetEvent有很多局限，比如不能跨进程使用，但它演示了通过基本的Monitor命令组合，达到事件机的作用。
现在是回答朋友们的疑问的时候了：
Q: Lock关键字不是有获取锁、释放锁的功能... 为什么还需要执行Pulse?
A: 因为Wait和Pulse另有用途。
Q: 用lock 就不要用monitor了(?)
A: lock只是Monitor.Enter和Monitor.Exit，用Monitor的方法，不仅能用Wait，还可以用带超时的Monitor.Enter重载。
Q: Monitor.Wait完全没必要 (?)
A: Wait和Pulse另有用途。
Q: 什么Pulse和Wait方法必须从同步的代码块内调用?
A: 因为Wait的本意就是“[暂时]释放对象上的锁并阻止当前线程，直到它重新获取该锁”，没有获得就谈不到释放。
补充：
按照《CLR via C#》中的说法，每个对象在被创建的时候，会被自动的添加两个信息，一是类型对象指针，二是同步块索引。
首先，CLR创建类Manager，在内存中分配 类Manager 所占用的空间，当创建Manager的实例M1的时候，M1的类型对象指针就指向Manager；
当用lock来锁定M1的时候，M1的同步块索引就指向一个同步块（这里说明一下同步块，CLR负责创建同步块，可以把它理解为一个数组，数组中的每一个元素就是一个同步块），M1的同步块索引初始为一个负数，表示M1没有同步，当用lock的时候，CLR负责在同步块数组中寻找空闲的同步块，并把M1的同步块索引被设置为一个整数S，S为找到的同步块在同步块数组中的索引，当lock结束之后，M1的同步块索引又被重新设置为负数。
如下图：
ObjectA的 SyncBlockIndex被设置为0，表示指向同步块数组中的索引为0的元素，
ObjectC的 SyncBlockIndex被设置为2，表示指向同步块数组中的索引为2的元素,
而ObjectB的 SyncBlockIndex被设置为-1，表示未指向任何同步块
