deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 08:53
Оценка:
Программа обрабатывает поступающую к ней очередь задач, создаёт на каждую задачу по два три потока.
Всё собираю с /MDd, единственная либа что использует msvcrtd.dll — curllibd.dll, который загружает ws_2.dll, а сокеты — msvcrtd.dll.
В тестовом прогоне, что описан ниже curl специально не использовался.

После непродолжительной нагрузки все дедлочится, список потоков выглядит так:
     3176    _initptd    _getch_nolock    Normal    0
     3856    _threadstartex    boost::thread::sleep    Normal    0
     2864    _threadstartex    _initptd    Normal    0
     3156    _threadstartex    _initptd    Normal    0
>    1524    _threadstartex    _endthreadex    Normal    0
     2704    _threadstartex    _endthreadex    Normal    0
     368    _threadstartex    _endthreadex    Normal    0
     3000    _threadstartex    _initptd    Normal    0
     3408    _threadstartex    _endthreadex    Normal    0
     1032    _threadstartex    _endthreadex    Normal    0
     1556    _threadstartex    _endthreadex    Normal    0
     3844    _threadstartex    TasksQueue::Lock    Normal    0
     3344    _threadstartex    _endthreadex    Normal    0
     3292    _threadstartex    TasksQueue::Lock    Normal    0
     200    _threadstartex    _endthreadex    Normal    0
     3672    _threadstartex    TasksQueue::Lock    Normal    0
     216    _threadstartex    _endthreadex    Normal    0

Call stack для 1524:
     ntdll.dll!KiFastSystemCallRet()     
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]    
     ntdll.dll!NtWaitForSingleObject()  + 0xc bytes    
     ntdll.dll!RtlLockHeap()  + 0x25c bytes    
     ntdll.dll!LdrShutdownThread()  + 0x32 bytes    
     kernel32.dll!ExitThread()  + 0x2f bytes    
>    msvcr80d.dll!_endthreadex(unsigned int retcode=0x00000000)  Line 414    C
     msvcr80d.dll!_callthreadstartex()  Line 348 + 0x15 bytes    C
     msvcr80d.dll!_threadstartex(void * ptd=0x01046090)  Line 331    C
     kernel32.dll!GetModuleHandleA()  + 0xdf bytes


Загружаемые модули:
ModLoad: 00400000 00609000   pro_service.exe
ModLoad: 7c800000 7c8c0000   ntdll.dll
ModLoad: 77e40000 77f42000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 10000000 10040000   C:\WORK\xxxxxx\HEAD\xxxxxx\debug\curllibd.dll
ModLoad: 71c00000 71c17000   C:\WINDOWS\system32\WS2_32.dll
ModLoad: 77ba0000 77bfa000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 71bf0000 71bf8000   C:\WINDOWS\system32\WS2HELP.dll
ModLoad: 77f50000 77feb000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77c50000 77cef000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 76f50000 76f63000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 76aa0000 76acd000   C:\WINDOWS\system32\WINMM.dll
ModLoad: 77380000 77411000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77c00000 77c48000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 10200000 10320000   C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_F75EB16C\MSVCR80D.dll
ModLoad: 00610000 006fa000   C:\WORK\xxxxxx\HEAD\xxxxxx\debug\tagd.dll
ModLoad: 10480000 1057c000   C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_F75EB16C\MSVCP80D.dll
ModLoad: 77670000 777a9000   C:\WINDOWS\system32\ole32.dll



Почти все потоки висят на RtlLockHeap, ни один дальше неё не ушёл, в своём коде никакого блокирования найти не могу.
Создаю потоки вот так:

UINT id;
HANDLE h = (HANDLE)_beginthreadex( 
    NULL, 
    0, 
    &_waiting_thread, 
    (void *) t, 
    CREATE_SUSPENDED , 
    &id );
if(h)
{
    ResumeThread(h);
    CloseHandle(h);
}


В чём может быть дело? Из-за чего потоки могут не закрываться?
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 09:26
Оценка:
Здравствуйте, Sergey Larionov, Вы писали:
SL>В чём может быть дело? Из-за чего потоки могут не закрываться?

Кстати, у меня в потоки передаются хендлы процессов, пайпов и евентов.
я делаю это так:
THREAD_PARAMS *param = new THREAD_PARAMS 
param->ev_terminate = CreateEvent( 
    NULL,         // default security attributes
    FALSE,         // manual-reset event
    FALSE,         // initial state is signaled
    (boost::wformat(L"terminate_pinger_%1%")%t->process_id).str().c_str()  // object name
); 

param->hPipeRd = hChildStdoutRdDup;
param->hPipeWr = hChildStdinWrDup;
DuplicateHandle( GetCurrentProcess (), param->ev_terminate, GetCurrentProcess() ,&(t->ev_terminate), 0, false, DUPLICATE_SAME_ACCESS);
DuplicateHandle( GetCurrentProcess (), param->hPipeRd, GetCurrentProcess() ,&(t->rd), 0, false, DUPLICATE_SAME_ACCESS);
DuplicateHandle( GetCurrentProcess (), param->hPipeWr, GetCurrentProcess() ,&(t->wr), 0, false, DUPLICATE_SAME_ACCESS);

hThread = (HANDLE)_beginthreadex(
    NULL, 
    0, 
    &convertor_listener, 
    (void *) param, 
    0, 
&dwThreadId );


Затем в потоке они закрываются
UINT  __stdcall convertor_listener(void *lpvParam)
{
    THREAD_PARAMS *params = (THREAD_PARAMS *)lpvParam;
...
    CloseHandle(params->ev_terminate);
    CloseHandle(params->hPipeRd);
    CloseHandle(params->hPipeWr);
    CloseHandle(params->siStartInfo.hStdInput);
    CloseHandle(params->siStartInfo.hStdOutput);
return 0;
}


Правильно делать Duplicate вообще, правильно ли в вызывающем потоке?
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[2]: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 11:08
Оценка:
Здравствуйте, Sergey Larionov, Вы писали:

SL>Здравствуйте, Sergey Larionov, Вы писали:
SL>>В чём может быть дело? Из-за чего потоки могут не закрываться?

SL>Кстати, у меня в потоки передаются хендлы процессов, пайпов и евентов.
SL>Правильно делать Duplicate вообще, правильно ли в вызывающем потоке?

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


SL>param->ev_terminate = CreateEvent(
SL> NULL, // default security attributes
SL> FALSE, // manual-reset event
SL> FALSE, // initial state is signaled

not signaled


1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 11:11
Оценка: 2 (1)
Здравствуйте, Sergey Larionov, Вы писали:

SL>Программа обрабатывает поступающую к ней очередь задач, создаёт на каждую задачу по два три потока.
SL>Всё собираю с /MDd, единственная либа что использует msvcrtd.dll — curllibd.dll, который загружает ws_2.dll, а сокеты — msvcrtd.dll.
SL>В тестовом прогоне, что описан ниже curl специально не использовался.

SL>После непродолжительной нагрузки все дедлочится, список потоков выглядит так:

SL>Почти все потоки висят на RtlLockHeap, ни один дальше неё не ушёл, в своём коде никакого блокирования найти не могу.

SL>В чём может быть дело? Из-за чего потоки могут не закрываться?

Первое, что приходит на ум, что какой-то поток умер "внутри" залоченного хипа, так и не разлочив мьютекс.
Посмотри в окне Output, нету ли там каких-либо ошибок и сообщений о завершении потоков.

1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: deadlock в _initptd и _endthreadex
От: Sergey Россия  
Дата: 20.03.08 11:23
Оценка: 1 (1)
> После непродолжительной нагрузки все дедлочится, список потоков выглядит
> так:
> 
>  3176 _initptd _getch_nolock Normal 0
>  3856 _threadstartex boost::thread::sleep Normal 0
>  2864 _threadstartex _initptd Normal 0
>  3156 _threadstartex _initptd Normal 0
>> 1524 _threadstartex _endthreadex Normal 0
>  2704 _threadstartex _endthreadex Normal 0
>  368 _threadstartex _endthreadex Normal 0
>  3000 _threadstartex _initptd Normal 0
>  3408 _threadstartex _endthreadex Normal 0
>  1032 _threadstartex _endthreadex Normal 0
>  1556 _threadstartex _endthreadex Normal 0
>  3844 _threadstartex TasksQueue::Lock Normal 0
>  3344 _threadstartex _endthreadex Normal 0
>  3292 _threadstartex TasksQueue::Lock Normal 0
>  200 _threadstartex _endthreadex Normal 0
>  3672 _threadstartex TasksQueue::Lock Normal 0
>  216 _threadstartex _endthreadex Normal 0
>


А завершения потоков вы случайно не в DllMain ждете? Если так, то скорее
всего не дождетесь.
А вообще, я с дедлоками обычно борюсь так — беру первый попавшийся поток,
смотрю на ожидании какого мьютекса он висит. Мьютексы у нас в проекте либо
CriticalSection, либо самописные — и у тех, и у других можно отладчиком
посмотреть, какой поток его занял. Результаты записываю на бумажку. Повторяю
итерацию для потока, занявшего мьютекс. Обычно в результате нескольких
итераций либо обнаруживаются "перекрещивающиеся" мьютексы, либо (редко)
выясняется, что какой-то поток забыл отпустить мьютекс и завершился.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 11:42
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Sergey Larionov, Вы писали:

R>Первое, что приходит на ум, что какой-то поток умер "внутри" залоченного хипа, так и не разлочив мьютекс.
R>Посмотри в окне Output, нету ли там каких-либо ошибок и сообщений о завершении потоков.

Вобщем сейчас поотлаживал, добился только того, что знаю когда всё встаёт.

Единственный повторяющийся параметр — одновременное выполнение функций _beginthreadex, _endthreadex в разных потоках.
Причём beginthreadex виснет так:
     ntdll.dll!KiFastSystemCallRet()     
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]    
     ntdll.dll!NtWaitForSingleObject()  + 0xc bytes    
     ntdll.dll!RtlLockHeap()  + 0x25c bytes    
     ntdll.dll!RtlCreateAcl()  + 0x62 bytes    
     ntdll.dll!LdrGetDllHandleEx()  + 0x8a bytes    
     ntdll.dll!LdrGetDllHandle()  + 0x18 bytes    
     kernel32.dll!GetModuleHandleW()  + 0x4f bytes    
     kernel32.dll!GetModuleHandleW()  + 0x159 bytes    
     kernel32.dll!GetModuleHandleW()  + 0x1f bytes    
     kernel32.dll!GetModuleHandleA()  + 0x1f bytes    
>    msvcr80d.dll!_initptd(_tiddata * ptd=0x00e45318, threadlocaleinfostruct * ptloci=0x003fed58)  Line 479 + 0xb bytes    C
     msvcr80d.dll!_beginthreadex(void * security=0x00000000, unsigned int stacksize=0x00000000, unsigned int (void *)* initialcode=0x004943cc, void * argument=0x00001f48, unsigned int createflag=0x00000000, unsigned int * thrdaddr=0x0121ff68)  Line 177 + 0x12 bytes    C
     pro_service.exe!WorkerProc(void * pParam=0x00000000)  Line 265 + 0x19 bytes    C++
     msvcr80d.dll!_callthreadstartex()  Line 348 + 0xf bytes    C
     msvcr80d.dll!_threadstartex(void * ptd=0x00e209d0)  Line 331    C
     kernel32.dll!GetModuleHandleA()  + 0xdf bytes

а _endthreadex так:
     ntdll.dll!KiFastSystemCallRet()     
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]    
     ntdll.dll!NtWaitForSingleObject()  + 0xc bytes    
     ntdll.dll!RtlLockHeap()  + 0x25c bytes    
     ntdll.dll!LdrShutdownThread()  + 0x32 bytes    
     kernel32.dll!ExitThread()  + 0x2f bytes    
>    msvcr80d.dll!_endthreadex(unsigned int retcode=0x00000000)  Line 414    C
     pro_service.exe!convertor_listener(void * lpvParam=0x00e4e3a0)  Line 1770 + 0x8 bytes    C++
     msvcr80d.dll!_callthreadstartex()  Line 348 + 0xf bytes    C
     msvcr80d.dll!_threadstartex(void * ptd=0x00e45248)  Line 331    C
     kernel32.dll!GetModuleHandleA()  + 0xdf bytes


Эта _initpd -> GetModuleHandle(KERNEL32) — всегда повторяется, на ней и лочится.
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[2]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 11:46
Оценка:
Здравствуйте, Sergey, Вы писали:

S>А завершения потоков вы случайно не в DllMain ждете? Если так, то скорее
S>всего не дождетесь.
Я их завершения нигде не жду, они самодостаточные все. Структуры с параметрами прямо в них удаляю, эти данные только в том потоке и используются, а хендлы сразу закрываю.

S>А вообще, я с дедлоками обычно борюсь так — беру первый попавшийся поток,
S>смотрю на ожидании какого мьютекса он висит. Мьютексы у нас в проекте либо
S>CriticalSection, либо самописные — и у тех, и у других можно отладчиком
S>посмотреть, какой поток его занял. Результаты записываю на бумажку. Повторяю
S>итерацию для потока, занявшего мьютекс. Обычно в результате нескольких
S>итераций либо обнаруживаются "перекрещивающиеся" мьютексы, либо (редко)
S>выясняется, что какой-то поток забыл отпустить мьютекс и завершился.

Да, спасибо, один перекрёстный мьютекс нашёл, но дело было, к сожалению, не в нём
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re: deadlock в _initptd и _endthreadex
От: Аноним  
Дата: 20.03.08 11:53
Оценка: 12 (2)
TerminateThread или SuspendThread не юзаете?
Re[2]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 11:59
Оценка:
Здравствуйте, Аноним, Вы писали:

А>TerminateThread или SuspendThread не юзаете?
Сейчас проверил — действительно юзаю, но я от него никак не ожидал.
Нужно избавиться?
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[2]: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 11:59
Оценка: 4 (1)
Здравствуйте, Sergey, Вы писали:

S>А завершения потоков вы случайно не в DllMain ждете? Если так, то скорее
S>всего не дождетесь.
S>А вообще, я с дедлоками обычно борюсь так — беру первый попавшийся поток,
S>смотрю на ожидании какого мьютекса он висит. Мьютексы у нас в проекте либо
S>CriticalSection, либо самописные — и у тех, и у других можно отладчиком
S>посмотреть, какой поток его занял. Результаты записываю на бумажку. Повторяю
S>итерацию для потока, занявшего мьютекс. Обычно в результате нескольких
S>итераций либо обнаруживаются "перекрещивающиеся" мьютексы, либо (редко)
S>выясняется, что какой-то поток забыл отпустить мьютекс и завершился.

Теперь это можно делать автоматически, без бумажки:
http://msdn2.microsoft.com/en-us/library/ms681622(VS.85).aspx

1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 12:01
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Sergey, Вы писали:

R>Теперь это можно делать автоматически, без бумажки:
R>http://msdn2.microsoft.com/en-us/library/ms681622(VS.85).aspx

Ух ты, крутая штука.
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[3]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 12:05
Оценка:
Здравствуйте, Sergey Larionov, Вы писали:

SL>Здравствуйте, Аноним, Вы писали:

А>>TerminateThread или SuspendThread не юзаете?
SL>Сейчас проверил — действительно юзаю, но я от него никак не ожидал.
SL>Нужно избавиться?
Я имею ввиду TerminateThread
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[3]: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 12:10
Оценка:
Здравствуйте, Sergey Larionov, Вы писали:

SL>Здравствуйте, remark, Вы писали:

R>>Здравствуйте, Sergey Larionov, Вы писали:

R>>Первое, что приходит на ум, что какой-то поток умер "внутри" залоченного хипа, так и не разлочив мьютекс.
R>>Посмотри в окне Output, нету ли там каких-либо ошибок и сообщений о завершении потоков.

SL>Вобщем сейчас поотлаживал, добился только того, что знаю когда всё встаёт.

SL>Единственный повторяющийся параметр — одновременное выполнение функций _beginthreadex, _endthreadex в разных потоках.

Ну они же оба висят на RtlLockHeap(), значит мьютекс кто-то раньше попортил.
Кстати, возможно просто идёт расстел памяти, и кто-то портит lock-word хипового мьютекса. Соотв. все потоки на нём виснут, т.к. ждут что его кто-то освободит, а его никто освобождать и не собирается.
Хммм... это вполне вероятно.
Можешь попробовать при старте программы найти адрес, где сидит lock-word хипового мьютекса, и поставить на него брик поинт, и дальше тупо и упорно смотреть, не модифицирует ли его кто-то левый.


SL>Эта _initpd -> GetModuleHandle(KERNEL32) — всегда повторяется, на ней и лочится.

GetModuleHandle это просто неправильный вывод отладчиком. Это не более чем стартовая точка всех потоков. Иногда она показывается как, например, 'strcmp'

1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 12:12
Оценка: 3 (1) +1
Здравствуйте, Sergey Larionov, Вы писали:

SL>Здравствуйте, Аноним, Вы писали:

А>>TerminateThread или SuspendThread не юзаете?
SL>Сейчас проверил — действительно юзаю, но я от него никак не ожидал.
SL>Нужно избавиться?



TerminateThread() как минимум к серьёзным утечкам памяти приводит. Если убивать в произвольном месте, то дедлок как пить дать словить

1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 12:19
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Sergey Larionov, Вы писали:

SL>>Здравствуйте, Аноним, Вы писали:

А>>>TerminateThread или SuspendThread не юзаете?
SL>>Сейчас проверил — действительно юзаю, но я от него никак не ожидал.
SL>>Нужно избавиться?

R>

R>TerminateThread() как минимум к серьёзным утечкам памяти приводит. Если убивать в произвольном месте, то дедлок как пить дать словить

Точняк! Убрал TerminateThread — всё заработало.
Тут дело всё в том, что я в одно место его бездумно вставил, а при использовании CreateThread этот дедлок славливался только через несколько дней работы.
Вот он, кровавый экспириенс.

Мне нужно было читать из пайпа, в который писал дочерний процесс, причём ReadFile не всегда отпускался, вынес его в поток, и по евенту завершения процесса терминейтил поток чтения. Через два месяца настигло

Спасибо, коллеги!
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[4]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 12:21
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Sergey Larionov, Вы писали:

SL>>Эта _initpd -> GetModuleHandle(KERNEL32) — всегда повторяется, на ней и лочится.

R>GetModuleHandle это просто неправильный вывод отладчиком. Это не более чем стартовая точка всех потоков. Иногда она показывается как, например, 'strcmp'

Да да, точно, про strcmp до меня давно дошло, а про это — только догадка, но я сам себе не верил
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
Re[2]: deadlock в _initptd и _endthreadex
От: Adriano  
Дата: 20.03.08 12:39
Оценка:
Здравствуйте, Sergey Larionov, Вы писали:

SL>Здравствуйте, Sergey Larionov, Вы писали:
SL>>В чём может быть дело? Из-за чего потоки могут не закрываться?

SL>Кстати, у меня в потоки передаются хендлы процессов, пайпов и евентов.
SL>я делаю это так:
SL>
SL>THREAD_PARAMS *param = new THREAD_PARAMS 
SL>param->ev_terminate = CreateEvent( 
SL>    NULL,         // default security attributes
SL>    FALSE,         // manual-reset event
SL>    FALSE,         // initial state is signaled
SL>    (boost::wformat(L"terminate_pinger_%1%")%t->process_id).str().c_str()  // object name
SL>); 

SL>param->hPipeRd = hChildStdoutRdDup;
SL>param->hPipeWr = hChildStdinWrDup;
SL>DuplicateHandle( GetCurrentProcess (), param->ev_terminate, GetCurrentProcess() ,&(t->ev_terminate), 0, false, DUPLICATE_SAME_ACCESS);
SL>DuplicateHandle( GetCurrentProcess (), param->hPipeRd, GetCurrentProcess() ,&(t->rd), 0, false, DUPLICATE_SAME_ACCESS);
SL>DuplicateHandle( GetCurrentProcess (), param->hPipeWr, GetCurrentProcess() ,&(t->wr), 0, false, DUPLICATE_SAME_ACCESS);

SL>hThread = (HANDLE)_beginthreadex(
SL>    NULL, 
SL>    0, 
SL>    &convertor_listener, 
SL>    (void *) param, 
SL>    0, 
SL>&dwThreadId );
SL>


SL>Затем в потоке они закрываются
SL>
SL>UINT  __stdcall convertor_listener(void *lpvParam)
SL>{
SL>    THREAD_PARAMS *params = (THREAD_PARAMS *)lpvParam;
SL>...
SL>    CloseHandle(params->ev_terminate);
SL>    CloseHandle(params->hPipeRd);
SL>    CloseHandle(params->hPipeWr);
SL>    CloseHandle(params->siStartInfo.hStdInput);
SL>    CloseHandle(params->siStartInfo.hStdOutput);
SL>return 0;
SL>}
SL>


SL>Правильно делать Duplicate вообще, правильно ли в вызывающем потоке?


DuplicateHandle имеет смысл вызывать если тебе надо передать handle в другой процесс, если же нет, то не надо создавать их копии, просто надо вовремя их закрыть.
Re[3]: deadlock в _initptd и _endthreadex
От: Sergey Россия  
Дата: 20.03.08 14:01
Оценка:
> S>А завершения потоков вы случайно не в DllMain ждете? Если так, то скорее
> S>всего не дождетесь.
> S>А вообще, я с дедлоками обычно борюсь так — беру первый попавшийся
> поток,
> S>смотрю на ожидании какого мьютекса он висит. Мьютексы у нас в проекте
> либо
> S>CriticalSection, либо самописные — и у тех, и у других можно отладчиком
> S>посмотреть, какой поток его занял. Результаты записываю на бумажку.
> Повторяю
> S>итерацию для потока, занявшего мьютекс. Обычно в результате нескольких
> S>итераций либо обнаруживаются "перекрещивающиеся" мьютексы, либо (редко)
> S>выясняется, что какой-то поток забыл отпустить мьютекс и завершился.
>
> Теперь это можно делать автоматически, без бумажки:
> http://msdn2.microsoft.com/en-us/library/ms681622(VS.85).aspx

Не, в моем случае наверное не получится. У нас read-write recursive mutex на
событиях реализован, а их WCT, насколько я понял, не умеет отслеживать. А
вообще полезная конечно штука.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: deadlock в _initptd и _endthreadex
От: remark Россия http://www.1024cores.net/
Дата: 20.03.08 14:20
Оценка:
Здравствуйте, Sergey, Вы писали:

>> S>А завершения потоков вы случайно не в DllMain ждете? Если так, то скорее
>> S>всего не дождетесь.
>> S>А вообще, я с дедлоками обычно борюсь так — беру первый попавшийся
>> поток,
>> S>смотрю на ожидании какого мьютекса он висит. Мьютексы у нас в проекте
>> либо
>> S>CriticalSection, либо самописные — и у тех, и у других можно отладчиком
>> S>посмотреть, какой поток его занял. Результаты записываю на бумажку.
>> Повторяю
>> S>итерацию для потока, занявшего мьютекс. Обычно в результате нескольких
>> S>итераций либо обнаруживаются "перекрещивающиеся" мьютексы, либо (редко)
>> S>выясняется, что какой-то поток забыл отпустить мьютекс и завершился.
>>
>> Теперь это можно делать автоматически, без бумажки:
>> http://msdn2.microsoft.com/en-us/library/ms681622(VS.85).aspx

S>Не, в моем случае наверное не получится. У нас read-write recursive mutex на
S>событиях реализован, а их WCT, насколько я понял, не умеет отслеживать. А
S>вообще полезная конечно штука.


Хммм... Ну в итоге-то ты всё равно блокирешься на объекте ядра, т.ч. я не вижу причин, причему WCT не может это отследить.


1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: deadlock в _initptd и _endthreadex
От: Sergey Larionov США  
Дата: 20.03.08 15:32
Оценка:
Здравствуйте, Adriano, Вы писали:

A>Здравствуйте, Sergey Larionov, Вы писали:
SL>>Правильно делать Duplicate вообще, правильно ли в вызывающем потоке?

A>DuplicateHandle имеет смысл вызывать если тебе надо передать handle в другой процесс, если же нет, то не надо создавать их копии, просто надо вовремя их закрыть.

Да, про это я знаю, но дело в том, что хэндлы у меня используются в двух дочерних тредах, в главном их завершение не отслеживается.
Нормально ли будет если я сделаю дубликат, и каждую копию закрою при завершении функции треда?
--
"To get the brain out was an easy part.
The hard part was to get the brain OUT"
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.