您的位置:首页 > 编程语言 > C#

C# Monitor Wait()和Pulse()

2018-02-28 15:00 344 查看

C# Monitor Wait()和Pulse()

 

1.Monitor.Wait方法
当线程调用 Wait 时,它释放对象的锁并进入对象的等待队列,对象的就绪队列中的下一个线程(如果有)获取锁并拥有对对象的独占使用。Wait()就是交出锁的使用权,使线程处于阻塞状态,直到再次获得锁的使用权。

2.Monitor.Pulse方法
当前线程调用此方法以便向队列中的下一个线程发出锁的信号。接收到脉冲后,等待线程就被移动到就绪队列中。在调用 Pulse 的线程释放锁后,就绪队列中的下一个线程(不一定是接收到脉冲的线程)将获得该锁。pulse()并不会使当前线程释放锁。

 

简述:

共用同一lock对象两线程不能只调用Wait(),Wait这个方法反而放弃了锁的使用权,同时阻塞当前线程,线程就直接休眠(进入WaitSleepJoin状态),同时在主线程中Join这个work线程时,也就一直不能返回了。线程将一直阻塞。

让我们首先看看MSDN对Monitor.Wait的解释(链接见注释):
释放对象上的锁并阻止当前线程,直到它重新获取该锁。...

该解释的确很粗糙,很难理解。让我们来看看它下面的备注:
同步的对象包含若干引用,其中包括对当前拥有锁的线程的引用、对就绪队列的引用和对等待队列的引用。

这个多少还给了点东西,现在我们脑海中想像这么一幅图画:

Assembly code
|- 拥有锁的线程 lockObj->|- 就绪队列(ready queue) |- 等待队列(wait queue)

当一个线程尝试着lock一个同步对象的时候,该线程就在就绪队列中排队。一旦没人拥有该同步对象,就绪队列中的线程就可以占有该同步对象。这也是我们平时最经常用的lock方法。
为了其他的同步目的,占有同步对象的线程也可以暂时放弃同步对象,并把自己流放到等待队列中去。这就是Monitor.Wait。由于该线程放弃了同步对象,其他在就绪队列的排队者就可以进而拥有同步对象。
比起就绪队列来说,在等待队列中排队的线程更像是二等公民:他们不能自动得到同步对象,甚至不能自动升舱到就绪队列。而Monitor.Pulse的作用就是开一次门,使得一个正在等待队列中的线程升舱到就绪队列;相应的Monitor.PulseAll则打开门放所有等待队列中的线程到就绪队列。

比如下面的程序:

C# code
class Program { staticvoid Main(string[] args) { new Thread(A).Start(); new Thread(B).Start(); new Thread(C).Start(); Console.ReadLine(); } staticobject lockObj =newobject(); staticvoid A() { lock (lockObj) //进入就绪队列 { Thread.Sleep(1000); Monitor.Pulse(lockObj); Monitor.Wait(lockObj); //自我流放到等待队列 } Console.WriteLine("A exit..."); } staticvoid B() { Thread.Sleep(500); lock (lockObj) //进入就绪队列 { Monitor.Pulse(lockObj); } Console.WriteLine("B exit..."); } staticvoidC() { Thread.Sleep(800); lock (lockObj) //进入就绪队列 { } Console.WriteLine("C exit..."); } }



从时间线上来分析:

Assembly code
T 线程A 0lock( lockObj ) 1 { 2 //... 线程B 线程C 3 //... lock( lockObj ) lock( lockObj ) 4 //... { { 5 //... //... 6 //... //... 7Monitor.Pulse //... 8Monitor.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...

 

 

 

由于Monitor.Wait的暂时放弃和Monitor.Pulse的开门机制,我们可以用Monitor来实现更丰富的同步机制,比如一个事件机(ManualResetEvent):
C# code
class MyManualEvent { privateobject lockObj =newobject(); privatebool hasSet =false; publicvoid Set() { lock (lockObj) { hasSet =true; Monitor.PulseAll(lockObj); } } publicvoid WaitOne() { lock (lockObj) { while (!hasSet) { Monitor.Wait(lockObj); } } } } class Program { static MyManualEvent myManualEvent =new MyManualEvent(); staticvoid 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(); } staticvoidWorkerThread(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的本意就是“[暂时]释放对象上的锁并阻止当前线程,直到它重新获取该锁”,没有获得就谈不到释放。


我们知道lock实际上一个语法糖糖,C#编译器实际上把他展开为Monitor.Enter和Monitor.Exit,即:
C# code
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:
C# code
lock(lockObj) { //...} ////相当于(DotNet 4):bool lockTaken =false; try { Monitor.Enter(lockObj,ref lockTaken); // } finally { if (lockTaken) Monitor.Exit(lockObj); }

现在Monitor.TryEnter在try的保护下,“加锁”成功意味着“放锁”将得到finally的保护。


注释和引用:
Monitor.Wait 方法 
http://msdn.microsoft.com/zh-cn/library/79fkfcw1.aspx

Monitor.TryEnter 方法
http://msdn.microsoft.com/zh-cn/library/dd289679.aspx

请问,多线程Monitor类
http://topic.csdn.net/u/20111206/15/744c70de-49dc-4694-a09e-180438d7f8f0.html

请问,这个关于多线程的代码不懂
http://topic.csdn.net/u/20111208/23/64671dd4-7fdc-4d76-b3b9-1fd18087e6e0.html
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: