Question

spoiler note: the question is the last phrase.

In C#, the classical pattern to use a condition variable is like this:

lock (answersQueue)
{
    answersQueue.Enqueue(c);
    Monitor.Pulse(answersQueue); // condition variable "notify one".
}

and some other thread:

lock (answersQueue)
{
    while (answersQueue.Count == 0)
    {
        // unlock answer queue and sleeps here until notified.
        Monitor.Wait(answersQueue);
    }
    ...
}

that’s an example taken from my code.
if I place the Pulse outside of the lock scope, it doesn’t compile.
however, it is the correct way:
c.f:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686903(v=vs.85).aspx
and:
http://www.installsetupconfig.com/win32programming/threadprocesssynchronizationapis11_7.html
(search for “inside”)

And indeed it is idiotic to signal the sleeping thread when you still are in your critical section. Because the sleeping thread CAN’T wake up (not immediately), BECAUSE it is INSIDE a criticial section as well !

Therefore, I hope that .NET or C# Pulse call is actually just flagging the lock object, so that when it goes out of scope it actually “pulses” the condition variable at this moment. Because otherwise, it would have an optimality issue.

So how come the design of the Monitor object was chosen to be that way ?

Edit:

I found the answer in this paper:
http://research.microsoft.com/pubs/64242/implementingcvs.pdf
section “Optimising Signal and Broadcast” and the previous section about NT kernel and how to make Condition Variable on top of Semaphores, which is the reason for introducing the “darned queues”.
NOW that makes me a better engineer.

Answer 1

And indeed it is idiotic to signal the sleeping thread when you still are in your critical section. Because the sleeping thread CAN’T wake up

Pulse doesn’t expect to get a thread running; it only expects to move a thread between the 2 queues (waiting and ready). The “not go do something” is part of releasing the lock via Exit (or the end of a lock). In reality, it isn’t an issue because Monitor.Pulse typically happens right before a Wait or an Exit.

Therefore, I hope that .NET or C# Pulse call is actually just flagging the lock object, so that when it goes out of scope it actually “pulses” the condition variable at this moment. Because otherwise, it would have an optimality issue.

Again; these are different issues: moving between waiting and ready is one thing; exiting a lock already has all the code to actually activate the next ready thread.