How to make sure the LPCRITICAL_SECTION i have is valid

xcavin

How to make sure the LPCRITICAL_SECTION i have is a valid one ?. ie, suppose some other thread called a DeleteCriticalSection() on the same pointer then the pointer becomes invalid and the behaviour is undefined. So how to make sure this has not happend.

Mark Salsbery

xcavin wrote:

So how to make sure this has not happend

Use good coding practices! Thread sync objects should be managed by one object/class/thread. Of course, you're free to code any way you want, but if this is an issue there's something wrong :) Mark

Mark Salsbery Microsoft MVP - Visual C++ "Great job team! Head back to base for debriefing and cocktails."

xcavin

How to make sure the LPCRITICAL_SECTION i have is valid ?

Mark Salsbery

It's valid from the time InitializeCriticalSection() is called until DeleteCriticalSection() is called. It's only a structure - there's no handle or function you can use to check its validity. It's up to you to manage its scope. Mark

Mark Salsbery Microsoft MVP - Visual C++ "Great job team! Head back to base for debriefing and cocktails."

xcavin

Mark Salsbery wrote:

It's only a structure - there's no handle or function you can use to check its validity. It's up to you to manage its scope.

From the dump using CDB i can see if its uninitialized. So was wondering if this can be done it from my program itslef so that there is no need to create dump !

David Crow

xcavin wrote:

...see if its uninitialized.

There really shouldn't be any reason for it not to be. This falls under the realm of good programming techniques.

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

xcavin

DavidCrow wrote:

There really shouldn't be any reason for it not to be. This falls under the realm of good programming techniques.

Sorry to be impolite Leave the programming techniques. My question is simple, if debugger can find it, how can it be done within my program ?

Mark Salsbery

How does the debugger find it? If I put the line CRITICAL_SECTION cs; in my code, it's uninitialized. In a debug build at runtime, the entire struct is filled with 0xCC bytes. The only way I see to check for validity is initialize the struct to some values that can never occur when the CS is initialized. Maybe: CRITICAL_SECTION cs; memset(&cs, 0xFF, sizeof(CRITICAL_SECTION)); It's hard to "Leave the programming techniques" when this shouldn't be an issue if it's used properly. Mark

Mark Salsbery Microsoft MVP - Visual C++ "Great job team! Head back to base for debriefing and cocktails."

xcavin

imagine a multiprocessor machine. The object which has a critical section member is deleted just before another thread tries to lock it. And on the destructor of this object delete_critical_section is called. I know to have a global synchronisation object and to resolve this issue, but that sync object would cost me lot time. And would be my last choice.

Mark Salsbery

Right. I'm following you. No thread should be deleting the critical section, except for a thread that's in charge of the lifetime of the critical section. The problem here is an object shouldn't be accessible by a thread when it's being destructed or after it's destructed. If an object has its own CS for access that's fine. In your scenario you also need synchronized access external from the object to control access to the object's scope/lifetime. Make sense? Mark

Mark Salsbery Microsoft MVP - Visual C++ "Great job team! Head back to base for debriefing and cocktails."

led mike

IMHO you are trying to solve the wrong problem.

xcavin wrote:

The object which has a critical section member is deleted just before another thread tries to lock it use it.

Your problem appears to be in your management "use model" of that object. The fact that it has a critical section member is irrelevant or perhaps even a bad design on it's own.

xcavin

led mike wrote:

IMHO you are trying to solve the wrong problem.

True, I agree. But can't help, need to fix this way. Cannot afford to reduce the speed any more :(

Mike Dimmick

Quite frankly the only reason to call DeleteCriticalSection is if you're containing a critical section within some dynamically allocated object. In which case, the code that deletes that object should delete the critical section. At process exit time, why waste the time to free the critical section? Windows is only going to throw away the whole address space anyway. Indeed, why free the contents of the heap? All DeleteCriticalSection really does is close the handle to the event object that was allocated if a thread ever had to block on entering the critical section. Windows closes handles that were still open when a process exited.

Stability. What an interesting concept. -- Chris Maunder

xcavin

Mike Dimmick wrote:

At process exit time, why waste the time to free the critical section?

Process should never exist. But unfortuantely another thread is hung after trying to use this deleted hence uninitialized criticalsection !

Stephen Hewitt

A critical section should be regarded as an opaque data structure. See here[^] for a description of what this means. Even if you did find a way to validate it you could only do so by ignoring the opaqueness: such techniques could break in a future OS or even after applying a service pack. David and Mark are giving you sound advice and my advice is to follow it.

Steve

Stephen Hewitt

This is need not be the case. Here's what critical sections currently look like:

typedef struct _RTL_CRITICAL_SECTION_DEBUG {
WORD Type;
WORD CreatorBackTraceIndex;
struct _RTL_CRITICAL_SECTION *CriticalSection;
LIST_ENTRY ProcessLocksList;
DWORD EntryCount;
DWORD ContentionCount;
DWORD Spare[ 2 ];
} RTL_CRITICAL_SECTION_DEBUG, *PRTL_CRITICAL_SECTION_DEBUG, RTL_RESOURCE_DEBUG, *PRTL_RESOURCE_DEBUG;

typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;

//
// The following three fields control entering and exiting the critical
// section for the resource
//

LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread; // from the thread's ClientId->UniqueThread
HANDLE LockSemaphore;
ULONG_PTR SpinCount; // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;

See here[^] for a description. In short all CRITICAL_SECTIONs are linked together link-list style and doing what you're suggesting may compromise the list and is thus likely to end in tears. As much as possible you should just follow the rules and try not to make any assumptions.

Steve

Hamid Taebi

See this[^] article does any help?

WhiteSky