Sign in to follow this  
g_tarun

Mutex lock __status

Recommended Posts

Hi All, Would greatly appriciate in any help in the following problem. Getting a deadlock problem in a multithread application using a Queue. I suspect the Mutex lock being used for this Queue goes into a state where __m_lock structure of Mutex has __status = 3. Following is the gdb dump of the QueueMgr. (gdb) print *this $2 = {<StatCollectorInf> = {_vptr.StatCollectorInf = 0xb7007098}, iQueueCount = 2048, ptHeadPtr = 0x8b79f84, ptTailPtr = 0x8b70038, ptFreeList = 0x0, iFreeNodes = 0, tEventQueueMutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 3, __spinlock = 0}}, waitingFeederCond = {__c_lock = {__status = 0, _spinlock = 0}, __c_waiting = 0x1, __padding = '\0' <repeats 20 times>, "d| \t\000\000\000", __align = 0}, waitingConsumerCond = {__c_lock = {__status = 0, _spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 27 times>, __align = 0}, bQueueStopped = false, flowControlEnabled = true, lowWaterMark = 1024, highWaterMark = 2048, waitingFeeders = 1, waitingConsumers = 0, sleepingFeeders = 1, sleepingConsumers = 1, feederData = {{condition = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x1, __padding = '\0' <repeats 20 times>, "d| \t\000\000\000", __align = 0}, count = 1}}, consumerData = {{condition = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x2527b4, __padding = "\000\000\000\000´'%\000\000\000\000\000³'%\000\000\000\000\000d| \t\000\000\000", __align = 0}, count = 1}}, minFeeder = 0, minConsumer = 0, iDequeueWaitTimeout = 0, _cleanupFunc = 0xb725cd7c <CCM_CCM_PktDispatcher::cleanupUnprocessedMsg(_queue_data)>, _name = {static npos = 4294967295, _M_dataplus = {<allocator<char>> = {<No data fields>}, _M_p = 0x8e01acc "PeerCCM[6004]-Dispatcher"}, static _S_empty_rep_storage = {0, 0, 51543, 0}}} This shows the QueueManager’s mutex state and Producer and consumer thread’s pthread condition (feederData & consumerData conditions) states. Mutex state seems to be wrong because __status ideally should have values 0, 1 or <address of waiting thread> as per the pthread lib. I suspect a glibc bug for this mutex state. I am using glibc 2.3.2-95.3 RHEL3. Thanks!! Tarun

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this