why in Monitor.Wait() Using of lock(object)

Question

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 4-Feb-11 12:31pm

User 7427435

Updated 4-Feb-11 13:14pm

Henry Minute

v2

Add a Solution

2 solutions

Solution 1

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.

Posted 4-Feb-11 13:27pm

Henry Minute

Updated 4-Feb-11 13:28pm

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

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-02-04T13:47:00

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