MFC CMutex issues

[mmingfeilam1]

Hi,

My company is writing a test harness in MFC to test out the Cantata telephone switch. we keep on running into issues when we are running the test harness with a lot of threads, ie >=40 threads. Attached is a screen shot of the assertion error that keeps on popping up. It complains about CMutex m_eventQueueCS not being a valid runtime class:

ASSERT(pObject->IsKindOf(RUNTIME_CLASS(CSyncObject)))

I suspect this is because of the invalid memory address that m_eventQueueCS occupies. This is probably due to the limited stack size assigned to the whole process, when the stack size is exceeded, then a thread can simply overwrite the existing stack memory, thereby causing memory problems. I tried to change m_eventQueueCS to use heap memory by doing this: m_eventQueueCS = new CMutex(); but it doesn't help.

Could there be a limit to the number of mutexex that you can have in an application/process?

Can anyone help shed some lights into this issue?

Thanks,

Mike Lam

[Arjay]

Can you better describe the architecture. I understand that tests are executed in threads and the tests test the telephone switch.

What isn't clear is whether the tests are completely independent of each other (i.e. no shared resources) or do the tests share resources (like multiple tests are accessing the tele switch.

While there is a limit on the amount of kernel objects in a process, it's much higher than 40. It is possible to run out of handles though, so make sure you are cleaning up all handles properly (while don't need to cleanup the CMutex objects per se, if you are using up the handles in other code, the CMutex object creation code will fail). This is probably unlikely because a process is limited to 65K handles and that's quite a few handles. You would have to run many short tests quickly and be leaking in order to run out of them. Btw, you can check the handle use of a process with task manager by expanding the columns - be sure to include thread and handle counts in the display.

I am wondering if you are using the CMutex properly. If the tests/threads share a resource, you need only one mutex to protect all the threads (rule of thumb == a sync object per shared resource) rather than a mutex per test/thread. Could this be the case?

[MikeAThon]

According to your screenshot, the ASSERT is on the line above the one you quoted. The ASSERT is on:
CSingleLock::CSingleLock(CSyncObject* pObject, BOOL bInitialLock)
{
ASSERT(pObject != NULL); // <-- ASSERT is here
ASSERT(pObject->IsKindOf(RUNTIME_CLASS(CSyncObject)));

m_pObject = pObject;
m_hObject = pObject->m_hObject;
m_bAcquired = FALSE;

if (bInitialLock)
Lock();
}
You are creating a CSingleLock object with a NULL critical section. Show the code which creates the CSingleLock object.

Mike

[upashu2]

Go through stacks (In your screenshot on left bottom, there is "Context" combobox, open it, choose next function.)
Most probably you will find out bug.

Also refer above posts.