Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Critical Data - Protect in a Library 2

Status
Not open for further replies.

sweep123

Technical User
May 1, 2003
185
GB
I have created a library which contains 2 interrupt routines (these are installed and run as the interrupt occurs).
However I have a problem, I get an Exception Handling Error after a few minutes of the program (which uses the library) running.

My question is what is the best way to protect the data that these interrupt routines are accessing. I think that at some time both interrupt routines are access the same data and corruption is occurring.

I am mindful that these routines have to run quickly and not consume too much processing time.

The error is:
First-chance exception at 0x78004df5 in AIMAPI_TEST.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x78004df5 in AIMAPI_TEST.exe: 0xC00000FD: Stack overflow.
 
1. Implement a class , let be it named Lock as follows:

class CLock
{
public:
CLock();
virtual ~CLock();
void Lock();
void Unlock();

private:
CRITICAL_SECTION mSection;
};

CLock::CLock()
{
InitializeCriticalSection(&mSection);
}

CLock::~CLock()
{
DeleteCriticalSection(&mSection);
}


void CLock::Lock()
{
EnterCriticalSection(&mSection);
}

void CLock::Unlock()
{
LeaveCriticalSection(&mSection);
}

2. Now everywhere you want to protect the code do the following:
- declare static CLock m_Lock;
- enclose the protected portion of code between :
m_Lock.Lock();
// protected code here
m_UnLock();


Example : lock a huge array while doing a binary serach

#include "Lock.h"

template <class Obj> class TComm
{
public:
//
private:
static CLock m_Lock;
//
};

template <class Obj> CLock TComm<Obj>::mLock; // initialize here


template <class Obj>
Obj* TComm<Obj>::BinarySearch(const Obj* obj) const

{
//
m_Lock.Lock();
// sort and Search protected
m_Lock.UnLock();
//
}
-obislavu-
 
That's great, but if you can use other libraries, you should know that this type of lock object has already been implemented more than once and there's no need to rewrite it yourself.

In MFC: CCriticalSection
In ATL: CComCriticalSection
 
Hi,
Okay, I indicated a simple way but there are many other solutions depending on your requirements and you find all them in MFC for example : CSingleLock, CMultiLock, CSemaphore, CMutex, CCriticalSection etc...
Think that all above assume synchronization objects and the classes with that objects are slightly slower than the same classes without.

-obislavu-
 
Thanks for the info.

I will use the CCriticalSection as I am using MFC.

But one other question.

For this library and its data, what checks can I use (via the complier and linker) to make sure that the data is safe; i.e. heap OK and array bound checks and storage OK.

The reason for using locks seems NOT to have solved the problem that for one particular libray call some array data seems to be a bit odd. The interface seems to be the problem.
 
In debug configurations (libcd.lib, libcmtd.lib, or msvcrtd.lib), you can use the function _CrtCheckMemory to verify the heap is OK. It can't check everything but it will catch if the heap structure itself is corrupted.

For array bounds checking, I don't think the compiler/linker has anything to help you out (but correct me if I'm wrong). There are some commercial debugging tools like Compuware's &quot;BoundsChecker&quot; you could use for that, I suppose.
 
The followings function helps you:
0. BOOL AfxCheckMemory( ) - This function validates the free memory pool and prints error messages as required
1. BOOL AfxIsValidAddress () - Checks any memory address to ensure that it is contained entirely within the program’s memory space
2. BOOL AfxIsValidString () - Determines whether a pointer to a string is valid
3. BOOL AfxIsMemoryBlock () - Checks a memory address to make sure it represents a currently active memory block that was allocated by the diagnostic version of new
4. VOID AfxCheckError () - Checks the return values of calls to OLE functions.
....
For array bounds you should encapsulate it in a class and there overload the [] operator with safe code checking.

-obislavu-
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top