多线程环境，其他线程永远无法访问关键部分

Question

Right now I am stuck, here is what I'm trying to do:

• Create 3 threads:
• These 3 threads will access a shared global resource (a vector)

At a certain point in the function (that all threads will call), there will be a Sleep(time) function, which makes the thread sleep, the function does not return. This is where I want another thread - thread 2, to access and use the function, modifying the global variable, until it sleeps, so thread 3 can access the function, ect...

The "critical section" function which accesses the global variable has an unspecified access time, it is never the same.

Initially, in main I call

    InitializeCriticalSection(&m_stCriticalSection);

What I attempted was, when this function is called, I immediately call

EnterCriticalSection(&m_stCriticalSection);

I then modify global variables, ect, then before the Sleep(time) I call

        LeaveCriticalSection(&m_stCriticalSection);         

Problem with this is, the other threads don't EVER get access to the function, even though I leave it. Is there a way for my other threads to continuously, or even every 5 seconds, get access to the critical section? Could my implementation be better?

So here's what I have now

void function() // all our threads will access this
{
   EnterCriticalSection(&obj)
   // manipulate global data
   LeaveCriticalSection(&obj)
   Sleep(long time) // another thread SHOULD NOW have access to this section!
   return true;
}

Answer 1

Is there any possibility that a process is failing in the "// manipulate global data" section?

If so, then LeaveCriticalSection(&obj) would never be called.

Have you tried putting debug logs right before LeaveCriticalSection(&obj)?

Answer 2

I think, it's more errorprone to use scoped-helpers which help you agains situation like 'some exception occurs after EnterCriticalSection() and before LeaveCriticalSection() so that LeaveCriticalSection() really never happens'.

You could do some wrapper (see above) around CS with some trace.

Also, I assume that it would be easy to collect the application dump and see via WinDbg current thread state & cs state.