Critical section queue - c++

Question

Is there no concept of queue in Windows critical sections?
I have the following render loop in a dedicated thread:
while (!viewer->finish)
{
EnterCriticalSection(&viewer->lock);
viewer->renderer->begin();
viewer->root->render(viewer->renderer);
viewer->renderer->end();
LeaveCriticalSection(&viewer->lock);
}
The main thread does message processing, and when I handle mouse events, I try to enter the same critical section, but for some reason, it runs the rendering thread for a thousand more iterations (around 10 seconds), before the main thread finally enters the critical section. What's causing this - even if there is no 'queue' to enter the section, shouldn't it be more like 50/50, instead of 99.9/0.1 like in my case? Both threads have 0 priority.
And what is a good way to add such queue? Would a simple flag like bDoNotRenderAnything suffice?
Edit: the solution in my case was simply to add an event object (a boolean variable would probably work too) that is set every time the message handler needs access to the critical section, and reset after using it. The renderer does not enter the section if the variable/event is set. This way message handler won't have to wait for more than one rendering iteration.

Answer 1

In older versions of Windows, critical sections were guaranteed to be acquired on a first-come first-served basis. This is no longer the case starting from Windows Server 2003 SP1.
From the MSDN:
Starting with Windows Server 2003 with Service Pack 1 (SP1), threads waiting on a critical section do not acquire the critical section on a first-come, first-serve basis. This change increases performance significantly for most code. However, some applications depend on first-in, first-out (FIFO) ordering and may perform poorly or not at all on current versions of Windows (for example, applications that have been using critical sections as a rate-limiter). To ensure that your code continues to work correctly, you may need to add an additional level of synchronization. For example, suppose you have a producer thread and a consumer thread that are using a critical section object to synchronize their work. Create two event objects, one for each thread to use to signal that it is ready for the other thread to proceed. The consumer thread will wait for the producer to signal its event before entering the critical section, and the producer thread will wait for the consumer thread to signal its event before entering the critical section. After each thread leaves the critical section, it signals its event to release the other thread.
Windows Server 2003 and Windows XP: Threads that are waiting on a critical section are added to a wait queue; they are woken and generally acquire the critical section in the order in which they were added to the queue. However, if threads are added to this queue at a fast enough rate, performance can be degraded because of the time it takes to awaken each waiting thread.

Answer 2

Threads waiting on a critical section do not acquire the critical section on a first-come, first-serve basis (MSDN)
Most of the time your worker thread owns the lock, because it re-locks immediately after it releases the lock. So there's not much time for the other thread to wake up and catch the lock when it's free.

Answer 3

According to MSDN
There is no guarantee about the order in which waiting threads
will acquire ownership of the critical section.
so it is not sure in which order threads will execute. And if your rather short
viewer->renderer->begin();
viewer->root->render(viewer->renderer);
viewer->renderer->end();
sequence manages to regain the CriticalSection over, this might happen.

Answer 4

You can try quick fix by using SwitchToThread call in your rendering loop (after certain number of iterations), although I doubt it will be good enough solution.