RE: [LCP]FW: pthread_mutex_lock call hangs

["Ajay Bansal" <Ajay_Bansal at infosys dot com>]

Title: Message

Hi All

 

I have been able to solve the problem. But the root cause is still not clear. Following is the scenario in the code.

 

I have a class CriticalSection which is being used in the class for locking.

 

Following is the class

typedef struct _critsection {
    pthread_t     Owner;
    int       LockDepth;
    pthread_mutex_t Lock;
} CRITICAL_SECTION;

 

typedef class CriticalSection {
public:
    CriticalSection() {  CriticalSectionLock.Owner = 0;  CriticalSectionLock.Lock = GenericMutexInitializer;      }
    int Lock() { return EnterCriticalSection(&CriticalSectionLock); } //for locking the mutex
    void Unlock() { LeaveCriticalSection(&CriticalSectionLock); } //for unlocking the mutex
private:
    CRITICAL_SECTION CriticalSectionLock;
}CCriticalSection;

 

 

My code uses the above class as

 

class myClass {

private

.

.

.

CCriticalSection myLock;

 

public:

void Lock(){myLock.Lock();}

};

 

main()

{

.

.

myClass *myObj = new myObj();

myObj.Lock()

 

.

.

.

}

 

 

Now in debug mode, initializer of "CriticalSection" is not being called. & then locking fails. As soon as I change  the name of class "CriticalSection" to some other name.. say "ACriticalSection". code works fine.

 

what can this mean?? & why this behaviour only in the debug mode?????

 

 

-----Original Message-----
From: Vincent Penquerc'h [mailto:Vincent dot Penquerch at artworks dot co dot uk]
Sent: Friday, March 07, 2003 11:03 PM
To: 'linuxcprogramming at lists dot linux dot org dot au'
Subject: RE: [LCP]FW: pthread_mutex_lock call hangs

> > Only difference between two build is of "-g" flag. There is

And about the link ? Are different libs being linked against ?
Sorry to state the obvious.
Only think I can think of is timing issues. Debug info in the exe
could *maybe* cause more disk load at startup, which could influence
the thread timing. Just a shot in the dark, really.
To make sure it's not something else that -g, strip your program
compiled with -g, and test it. Stripped program should be the same
as the release one.

(Sorry about the HTML, it's converted after my mailer sends plain
text).

--
Vincent Penquerc'h