Possible Deadlock in C++ API?
Posted: 20 Aug 2015, 10:44
We are seeing some situations (infrequent - but does happen), where SmartFox appears to be deadlocked between locks in ThreadManager, mtxDisconnect, and mutexes for reading from TCPClient. Everything stops responding but the app doesn't crash. Please see the attached 2 screenshots showing where this lock contention is taking place in SFS2X C++ code. We think we've fixed this by changing ThreadManager in this way:
Notice how the lock is shortened to only lock popping from the queue and not to also lock the actual processing of the input or output item.
Please take a look at this for us in more detail and provide us a more official patch for this issue. Thanks!
Code: Select all
void ThreadManager::InThread()
{
boost::posix_time::milliseconds workTime(5);
while (running)
{
boost::this_thread::sleep(workTime);
if (running == false) break;
boost::shared_ptr<map<string, boost::shared_ptr<void> > > item;
while (true)
{
inQueueLocker.lock();
if(inThreadQueue->size() <= 0) {
inQueueLocker.unlock();
break;
}
item = inThreadQueue->front();
inThreadQueue->pop_front();
inQueueLocker.unlock();
ProcessItem(item);
item->clear();
}
}
}
Code: Select all
void ThreadManager::OutThread()
{
boost::posix_time::milliseconds workTime(5);
while (running)
{
boost::this_thread::sleep(workTime);
if (running == false) break;
boost::shared_ptr<map<string, boost::shared_ptr<void> > > item;
while (true)
{
outQueueLocker.lock();
if (outThreadQueue->size() <= 0) {
outQueueLocker.unlock();
break;
}
item = outThreadQueue->front();
outThreadQueue->pop_front();
outQueueLocker.unlock();
ProcessOutItem(item);
item->clear();
}
}
}
Notice how the lock is shortened to only lock popping from the queue and not to also lock the actual processing of the input or output item.
Please take a look at this for us in more detail and provide us a more official patch for this issue. Thanks!