An example of this is in the handling of OsMsgPool.
On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think I might have found a flaw in the design of locking used in
sipXtapi and other libraries.
The problem is basically, that in general we have a class like this :
class SomeClass
{
OsMutex *lock;
int someMember;
public:
SomeClass()
{
lock = new OsMutex(OsMutex::Q_PRIORITY |
OsMutex::DELETE_SAFE |
OsMutex::INVERSION_SAFE);
}
~SomeClass()
{
lock->acquire();
// some other stuff ...
delete lock;
}
int getSomeMember()
{
OsLock(lock);
return someMember;
}
};
I think lock member is not thread safe to delete in SomeClass.
Lets imagine we have 2 threads:
T1: a = new SomeClass();
T1: delete a;
T1: now we get into ~SomeClass()
T1: lock->acquire();
now context switch to T2:
T2: b = a->getSomeMember()
T2: we get into getSomeMember
T2: OsLock(lock); // but lock is already locked so we wait
context switch to T1:
T1: delete lock;
T1: leave destructor
context switch to T2:
T2: we are in deleted instance in lock!! What would really happen now??,
later in the function we read someMember which doesnt exist.
Btw in OsMutexWin constructor, parameters are ignored, so
OsMutex::DELETE_SAFE has no meaning!
I know that "delete this;" statement works if its the last statement in
a function, and destructor is empty, but has anyone thought about the
problem with OsMutex?
Unlocking lock in destructor is not right, as then we would certainly
get a crash in T2. Locks have to be locked when they are deleted.
Jaro
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
--
Keith Kyzivat
SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
