今天早上,例行巡查服務(wù)器,我用strace命令跟蹤服務(wù)器進(jìn)程的時(shí)候, 發(fā)現(xiàn)有幾個(gè)服務(wù)器進(jìn)程出現(xiàn)了死鎖情況, gdb繼續(xù)跟進(jìn),顯示如下:
gdb) bt
#0 0x00ff9410 in __kernel_vsyscall ()
#1 0x004d593e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2 0x00465b38 in _L_lock_14080 () from /lib/libc.so.6
#3 0x00464df4 in free () from /lib/libc.so.6
#4 0x006c7691 in operator delete () from /usr/lib/libstdc++.so.6
#5 0x08059cfb in __gnu_cxx::new_allocator<std::_List_node<TTimeEvent> >::deallocate (this=0x98e0064, __p=0x98e1218)
at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/ext/new_allocator.h:94
#6 0x08059d20 in std::_List_base<TTimeEvent, std::allocator<TTimeEvent> >::_M_put_node (this=0x98e0064, __p=0x98e1218)
at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_list.h:320
#7 0x08059d81 in std::list<TTimeEvent, std::allocator<TTimeEvent> >::_M_erase (this=0x98e0064, __position=
{_M_node = 0x98e1218}) at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_list.h:1150
#8 0x08059db3 in std::list<TTimeEvent, std::allocator<TTimeEvent> >::pop_front (this=0x98e0064)
at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_list.h:747
#9 0x08059334 in CTimerManager::Process (this=0x98e0058) at src/timermanager.cpp:168
#10 0x080597dd in Process (nSigNo=14) at src/timermanager.cpp:199
#11 <signal handler called>
#12 0x004612ba in _int_free () from /lib/libc.so.6
#13 0x00464e00 in free () from /lib/libc.so.6
#14 0x006c7691 in operator delete () from /usr/lib/libstdc++.so.6
#15 0x006a424d in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6
#16 0x0069e40f in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf ()
from /usr/lib/libstdc++.so.6
#17 0x0069fd7f in std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_stringstream ()
from /usr/lib/libstdc++.so.6
#18 0x080524ea in CDBMoudle::Insert (this=0x98e6e80, tFixkey=@0xbfe1c6ec) at src/dbmoudle.cpp:59
#19 0x08051718 in CConnectionTask::ProcFixContent (this=0x98e6510) at src/connectiontask.cpp:218
#20 0x0805196e in CConnectionTask::HandleRead (this=0x98e6510) at src/connectiontask.cpp:86
#21 0x08051a0f in CConnectionTask::Handle (this=0x98e6510, nEvent=1) at src/connectiontask.cpp:52
#22 0x080585af in IServer::Run (this=0xbfe1c7e0) at src/server.cpp:133
#23 0x08055328 in main (argc=2, argv=0xbfe1c8b4) at src/main.cpp:19
在#13處,調(diào)用free函數(shù), 然后進(jìn)入與之相關(guān)的libc函數(shù)調(diào)用中.但是, 在這個(gè)調(diào)用還沒有完結(jié)之前被定時(shí)器管理模塊中斷, 進(jìn)入了定時(shí)器處理的部分, 在在這個(gè)處理中同樣調(diào)用了free函數(shù), 于是出現(xiàn)了死鎖的情況--因?yàn)閙alloc/free函數(shù)族不是可重入的, 在
這里有一篇相關(guān)的文章.
我曾經(jīng)想在我的服務(wù)器代碼中盡量減少對(duì)象的構(gòu)造/析構(gòu), 但是想了一下, 這個(gè)策略不是治本的辦法, 這意味著我必須在寫代碼的時(shí)候處處小心, 今天可能在A處出現(xiàn)死鎖, 明天可能會(huì)在B處出現(xiàn).而且, 由于使用的是C++, 一些局部對(duì)象的構(gòu)造和析構(gòu)是不可避免的.
于是, 解決這個(gè)問題的思路就改變?yōu)?盡量的簡(jiǎn)單化定時(shí)器處理操作.目前我想到的一個(gè)策略時(shí), 一個(gè)定時(shí)器被觸發(fā)的時(shí)候, 置一個(gè)標(biāo)志位, 而不是在在觸發(fā)的時(shí)候調(diào)用相應(yīng)的處理函數(shù), 然后在服務(wù)器的主循環(huán)中判斷是否被置位, 如果是的話再去調(diào)用相關(guān)的處理函數(shù).
于是, 原來(lái)的思路就是:
// 該函數(shù)在定時(shí)器到時(shí)的時(shí)候被觸發(fā)
void signal()
{
// 定時(shí)器處理函數(shù)
dosomething();
}
while(1)
{
服務(wù)器主循環(huán);
}
修改之后的思路是:
int violate g_alarm = 0;
// 該函數(shù)在定時(shí)器到時(shí)的時(shí)候被觸發(fā)
void signal()
{
g_alarm = 1;
}
while(1)
{
服務(wù)器主循環(huán);
if (g_alarm)
{
// 定時(shí)器處理函數(shù)
dosomething();
g_alarm = 0;
}
}
這是大概的模型上面的改變.這是我目前能想到的處理該問題的最好辦法, 如果哪位有更好的辦法歡迎補(bǔ)充.