Click here to Skip to main content
15,881,248 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
Why in Monitor.Pulse() and Monitor.Wait() Using of

C#
lock (object)
{
  Monitor.Pulse();
  // or
  Monitor.Wait();
}


but in Monitor.Enter() & Monitor.Exit() do not use?
Posted
Updated 4-Feb-11 13:14pm
v2

That's correct.

The brackets Monitor.Enter() ... Monitor.Exit() play the role analogues to that of lock statement. The expression under the lock or in the lock block implicitly bracket the code in "get lock" ... "release lock". In the same way, Monitor.Enter will hold all the thread in the wait queue until the thread currently owning a monitor exits, which is "already thread-safe", it already ensures mutual exclusion operation as the lock would.

In contrast, "The Pulse, PulseAll, and Wait methods must be invoked from within a synchronized block of code." (Microsoft, see http://msdn.microsoft.com/en-us/library/system.threading.monitor.pulse.aspx[^]).

Look at the sample from the same help page.

One thread is feeding data in a queue, another thread is consuming the data from the same queue. As a call to Pulse if a non-blocking call; and operation depends on the order of calls to Pulse and Wait. To ensure that this order of operations is not broken be the other thread's operation interlaced with the other (race condition, http://en.wikipedia.org/wiki/Race_condition[^]), the operations have to be done in mutually exclusive order, that is guaranteed by the lock on the same object as Wait and Pulse; this object is a queue itself. This is not a problem to re-use the queue as a data container and a lock object at the same time, because this object is private (not public or internal).

—SA
 
Share this answer
 
v6
Comments
Espen Harlinn 5-Feb-11 13:30pm    
Good reply
Sergey Alexandrovich Kryukov 6-Feb-11 12:41pm    
Thank you Espen.
OP gives us pretty interesting questions.
However, for the very first time I refrained from answering another question, see this:
http://www.codeproject.com/Questions/154189/problem-with-lock-in-thread-managment-lock.aspx
The problems are apparent, but looking at the previous questions/answers shows the problems in application of the answers in programming, as if all answers are ignored.
Not that I want to blame OP (it could be just a matter of skills), I simply don't know how to help.
--SA
Do you ever read the documentation before you ask these questions? :)

From the Monitor Class page on MSDN:

The functionality provided by the Enter and Exit methods is identical to that provided by the C# lock statement (SyncLock in Visual Basic), except that lock and SyncLock wrap the Enter(Object, Boolean) method overload and the Exit method in a try-finally block (Try-Finally in Visual Basic) to ensure that the monitor is released.
 
Share this answer
 
v2
Comments
Sergey Alexandrovich Kryukov 4-Feb-11 22:41pm    
That's correct, but still does not answer the first part of question: why Pulse and Wait should be bracketed with the lock. (I tried, please see my answer.) The technique seems more or less obvious, but the explanation what exactly might go wrong without the lock might require pretty cunning logic. For mutex classical examples are written (flip the order get/release in one of the nested blocks and get a deadlock, not mentioning famous Dining Philosophers problem). The .NET monitor functionality is more exotic, complex and not used often.

--SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900