Необъяснимое повышение поведения :: scoped_lock

Я написан на C ++ многопоточном TCP-сервере, для синхронизации с использованием boost: scoped_lock

После подключения к серверу клиент зависает.

в GDB я видел больше потоков в pthread_kill после вызова boost :: mutex :: lock

(gdb) info thread

277 Thread 808779c00 (LWP 245289330/xgps)  0x0000000802579d5c in poll () at poll.S:3
276 Thread 808779800 (LWP 245289329/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
275 Thread 808779400 (LWP 245289328/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
.....
246 Thread 808c92800 (LWP 245289296/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
245 Thread 808643800 (LWP 245289295/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
244 Thread 808643400 (LWP 245289294/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
243 Thread 806c8f400 (LWP 245289292/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
242 Thread 808643000 (LWP 245286262/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
241 Thread 808c92400 (LWP 245289288/xgps)  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3[Switching to thread 205 (Thread 80863a000 (LWP 245289251/xgps))]#0  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
(gdb) where
#0  0x00000008019799bc in pthread_kill () from /lib/libthr.so.3
#1  0x0000000801973cfc in pthread_getschedparam () from /lib/libthr.so.3
#2  0x00000008019782fc in pthread_mutex_getprioceiling () from /lib/libthr.so.3
#3  0x000000080197838b in pthread_mutex_lock () from /lib/libthr.so.3
#4  0x0000000000442b2e in boost::mutex::lock (this=0x803835f10) at mutex.hpp:62
#5  0x0000000000442c36 in boost::unique_lock<boost::mutex>::lock (this=0x7fffe7334270) at lock_types.hpp:346
#6  0x0000000000442c7c in unique_lock (this=0x7fffe7334270, m_=@0x803835f10) at lock_types.hpp:124
#7  0x0000000000466e31 in XDevice::getDeviceIMEI (this=0x803835e20) at /home/xgps_app/device.cpp:639
#8  0x000000000049071f in XDevicePool::get_device (this=0x7fffffffd9c0, device_imei=868683024674230) at /home/xgps_app/pool_devices.cpp:351

Код в строке device.cpp: 639

IMEI
XDevice::getDeviceIMEI()
{
try {
boost::mutex::scoped_lock lock(cn_mutex);
return  device_imei;
}
catch (std::exception &e )
{
cout << " ERROR in getDeviceIMEI " << e.what() << "\n";
}
return 0;
}

Код в pool_device

XDevicePtr
XDevicePool::get_device(IMEI device_imei)
{
XDevicePtr device;
unsigned int i = 0;

while(i < this->devices.size())
{
device = devices[i];
if (device->getDeviceIMEI() == device_imei) {
LOG4CPLUS_DEBUG(logger,  "XDevicePool::get_device found!");
return device;
}
i++;
}
device.reset();
return device;
}

XDevicePtr
XDevicePool::get_device_mt(IMEI device_imei)
{
try
{
boost::mutex::scoped_lock lock(pool_mutex);

}
catch (std::exception & e)
{
LOG4CPLUS_ERROR(logger,  "XDevicePool::get_device error! " << e.what());
}
//  boost::mutex::scoped_lock lock(pool_mutex);
return get_device(device_imei);
}

Почему после вызова мьютекса блокировка потока завершается?
Я думаю, что тупик не причина для такого поведения
Пожалуйста помоги!

1

Решение

ТЛ; др pthread_kill скорее всего красная сельдь.

Почему после вызова мьютекса блокировка потока завершается?

Это не так. Ваши темы не были прерваны (о чем они по-прежнему свидетельствуют info thread).

Вы, кажется, предполагаете, что pthread_kill убивает текущий поток. На самом деле, что pthread_kill делает это отправить сигнал в другой поток. И даже отправка необязательна (если sig=0).

Увидеть справочная страница для дальнейших деталей.

0

Другие решения

У вас есть несколько замков.

Всякий раз, когда у вас есть несколько блокировок, которые могут потребоваться одновременно, вам нужно получить их в фиксированном порядке, чтобы избежать тупиковой блокировки.

Кажется вероятным, что у вас возникла такая тупиковая ситуация. Смотрите бесплатную функцию Boost Thread boost::lock http://www.boost.org/doc/libs/1_63_0/doc/html/thread/synchronization.html#thread.synchronization.lock_functions.lock_multiple за помощь в приобретении нескольких замков в надежном порядке.

Вы также хотите знать о std::defer_lock,


Помимо этого, могут быть помехи от fork в многопоточных программах. Я думаю, что это сейчас выходит за рамки объяснения, если вы действительно не используете fork в вашем процессе

0

По вопросам рекламы [email protected]