> Well, it actually helps debugging on the client site. Just
> ask the client
> which has encountered the problem to supply the log file for
> her system to
> you, and use that file to get a figure of what happened that
> the deadlock
> occurred.
To minimize the disturbance to the threads, what I do in my logging
routine is this:
class CDebuggingLogger
{
public:
CDebuggingLogger(const char* pszFilename)
{
m_fp = fopen(pszFilename, "w");
ASSERT(m_fp);
}
void Log(const CString& strComment)
{
if (m_fp)
m_astrLines.Add(strComment);
};
~CDebuggingLogger()
{
if (m_fp)
{
for (int i = 0; i < m_astrLines.GetSize(); i++)
fputs(m_astrLines[i], m_fp);
fclose(m_fp);
}
};
private:
CArray<CString,CString> m_astrLines;
FILE* m_fp;
};
CDebuggingLogger s_dlLog("c:\\temp\\Log.txt");
void Something()
{
s_dlLog.Log("Got Here\n");
}
This makes the Log() function as quick as possible so the threads are
disturbed as little as possible. Unfortunately, the file doesn't get
written out if the program crashes. Does any one have a suggestion for
getting the file written if there the program crashes without causing
more time to be spent in the Log() function?
> > I am thinking of writing a program that creates a set of events (one
> > for each thread in my app), and has a button that triggers
> that event.
> >
> > Then I would sprinkle WaitForSingleEvent() calls all over my code.
> > Then my program would be a "puppet" of the other one and the threads
> > would run in a completely deterministic order.
>
> But would that simlate real world usage of your app? Doesn't
> seem to me
> like that.
It wouldn't simulate the real world, true, but we can't simulate the
real world here in all its difference in data rates and computer speeds
and amounts of RAM, etc, anyway. At least if I find a case that doesn't
work I can reproduce it.
> Do you have any idea what is causing the race condition?
I'm guessing that the threads are running at very different rates when
the CPU gets bogged down. We have one higher priority thread (that needs
to guarantee that we don't lose data), and we think that on slow systems
it starts hogging. That's why I'd like to have a way to artificially
block a thread momentarily to change the order of execution.
But that is just a guess. We're not even sure it is caused by high data
rates. Upping the data rate caused the crash on one computer in the
field, but upping the data rate on any of the computers in the office
didn't cause a problem.
