Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Delphi: WinAPI и системное программирование > Таймаут на выполнение потока

Автор: RA 13.12.2009, 20:25

Вот недавно столкнулся с сетевой задачей где требовалось реализовать множество потоков, при этом поток должен был завершиться либо самостоятельно в результате получения ответа от сервера, либо принудительно по истечению таймаута.  Для простоты и удобства я использовал класс TThread, и внутри каждого потока создавал таймер который собственно и отвечал за таймаут выполнения потока.  Ну и как бы на тестовой сборке в 10 и 100 потоков всё работало как часы "Patek Philippe", потом на сборке в 1000 потоков (при том что ресурс таймера до 10000 штук), начались непонятности ввиде Unexpected и Unknown error-ов. Я поначалу начал грешить на таймеры, и убил неделю прежде чем нашёл истинную причину косяков, но осадок как в известном анегдоте остался в отношении использования таймеров внутри потока.  Вобщем я пережил дикий стресс из-за которого у меня теперь психологический барьер на использование таймеров  . Хотелось бы увидеть мнения участников по поводу способов таймаута на выполнение потоков в многопотчных приложениях.

Автор: VictorTsaregorodtsev 13.12.2009, 21:44

RA, баги были скорее всего из-за того, что число дескрипторов в операционке переполнялось (кроме хэндла для каждого потока создавались еще и один или даже два хендла на любой поток, который выводит инфу на экран, т.е. пользуется функциями из системной либы user.dll). Рихтер об этом писал, но не акцентировал, ибо необходимость тысяч потоков для реальной задачи представляется сомнительной  А если еще внутри каждого потока создавались какие-то объекты ядра либо потоки убивались (до смерти, CloseHandle'ом) только при завершении проги (а не после окончания работы потока), то тогда точно было переполнение числа дескрипторов. Ну а по заданному вопросу... Курить ВинАПИ и как-то перепроектировать логику работы проги. Ибо в диспетчере задач Виндов можно увидеть, что все нужды операционки (в т.ч. и сетевые) укладываются в сотни две-три потоков.

Автор: Voxifer 14.12.2009, 00:57

Цитата(VictorTsaregorodtsev @  13.12.2009,  21:44 ) число дескрипторов в операционке переполнялось Сомнительно как-то. Теретически - максимальное число хендлов 65536, практически - HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota (10000). Сомневаюсь, что даже в 1000 потоках можно было бы открыть и держать десятку хендлов. Цитата(RA @  13.12.2009,  20:25 ) Вобщем я пережил дикий стресс из-за которого у меня теперь психологический барьер на использование таймеров  Не зная твоего кода, можно лишь предполагать, что, возможно, ты не учел низкоприоритетность таймеров, что на фоне высокой загрузки приложения могло отозваться пропуском сообщений таймеров. Ну и есть, конечно, подозрения на твоё "принудительное" завершение потока, может быть оно проходило без освобождения ресурсов. В любом случае, использовать низкоточный системный таймер в таймаутах потоков при условии высокой нагрузки, мне кажется, не есть айс. Гораздо проще сделать Sleep(50) в цикле N раз, где  N = таймаут/50. Ну или использовать высокоточный системный таймер. По крайней мере, я бы с этого начал, если бы у меня была аналогичная задача...

Автор: dumb 14.12.2009, 05:25

Цитата(RA @  13.12.2009,  20:25 ) но осадок как в известном анегдоте остался в отношении использования таймеров внутри потока. при создании таймера вызывается AllocateHWnd, которая ни разу не thread-safe ps. хотя, возможно в свежих версиях дельфей этот момент исправлен

Автор: Демо 14.12.2009, 10:00

Цитата(dumb @  14.12.2009,  05:25 ) при создании таймера вызывается AllocateHWnd, которая ни разу не thread-safe Поясни плиз не "thread-safe"-вость. В чём она здесь заключается? RA,  Проблему без кода вряд ли можно понять. Скорее всего реализация с ошибкой, которая проявляется при недостатке ресурсов (процессора, памяти, например).

Автор: Alca 14.12.2009, 10:14

А че за таймер то? TTimer или WaitableTimer (WinAPI)?

Автор: Alexeis 14.12.2009, 10:15

Цитата(dumb @  14.12.2009,  04:25 ) при создании таймера вызывается AllocateHWnd, которая ни разу не thread-safe   Это при использовании компонента? Я имею ввиду, может таймер создается в каждый в своем потоке при помощи CreateTimer.

Автор: Демо 14.12.2009, 10:45

Цитата(Alexeis @  14.12.2009,  10:15 )   Это при использовании компонента? Да и с TTimer никаких проблем нет. Прекрасно будет работать в потоках.

Автор: dumb 16.12.2009, 01:55

Цитата(Демо @  14.12.2009,  10:00 ) Поясни плиз не "thread-safe"-вость. В чём она здесь заключается? http://qc.embarcadero.com/wc/qcmain.aspx/qcmain.aspx?d=47559 Цитата(Демо @  14.12.2009,  10:45 ) Да и с TTimer никаких проблем нет. Прекрасно будет работать в потоках.  как и всегда в таких случаях - до определенного момента.

Автор: Демо 16.12.2009, 04:03

dumb,  Да, действительно - MakeObjectInstance использует глобальную переменную. Хоть и вероятность одновременного использования очень мала, но тем не менее это место для возникновения сбоев в программе. Спасибо за информацию. Тем не менее использование TTimer в дополнительных потоках никак не связано с этой ошибкой в генетическом коде. Зная о ней, достаточно будет использовать глобально критическую секцию для создания сколько угодно TTimer в потоках...

Автор: RA 16.12.2009, 21:22

dumb, весьма полезно!

Автор: Alexeis 16.12.2009, 21:46

Цитата(Демо @  16.12.2009,  03:03 ) Зная о ней, достаточно будет использовать глобально критическую секцию для создания сколько угодно TTimer в потоках...    Поиск по исходникам показал что вызов "Classes.AllocateHWnd" присутствует 5 раз, так что критическая секция для таймера не спасет.

Автор: Демо 17.12.2009, 01:25

Цитата(Alexeis @  16.12.2009,  21:46 ) что вызов "Classes.AllocateHWnd" присутствует 5 раз, В TTimer?

Автор: Демо 17.12.2009, 05:38

Alexeis,  Вроде как получается, что надо генетический материал поправить...

Автор: Alexeis 17.12.2009, 10:31

Цитата(Демо @  17.12.2009,  00:25 ) В TTimer?    В том то и дело что нет, т.е. теоретически вызов Classes.AllocateHWnd из основного потока и вызов из конструктора таймера в отдельном потоке могут совпасть во времени.    Цитата(Демо @  17.12.2009,  04:38 ) Вроде как получается, что надо генетический материал поправить...   Что значит "генетический материал"? Перекомпилить VCL?

Автор: Демо 17.12.2009, 12:37

Цитата(Alexeis @  17.12.2009,  10:31 ) Что значит "генетический материал"? Перекомпилить VCL? Ну да. Classes.pas.

Автор: Alexeis 17.12.2009, 12:53

Цитата(Демо @  17.12.2009,  11:37 ) Ну да. Classes.pas.    Насколько я знаю перекомпиляция отдельных файлов VCL невозможна в связи с тем, что многие модули VCL тесно переплетены в юзесах, в результате потребуется перекомпиляция порядка сотни различных модулей. Сам посмотри. Любой компонент наследник TComponent, значит у него в юзесах есть Classes.pas. Но на этом счастье не заканчивается. Чтобы все правильно работало потребуется перекомпиляция всех bpl как рантайма так и дизайн тайма где используются измененные модули. Вообщем, компиляция всего и вся что только можно откомпилировать  . аццкая работа

Автор: RA 6.1.2010, 16:28

Цитата(VictorTsaregorodtsev @  13.12.2009,  21:44 ) баги были скорее всего из-за того, что число дескрипторов в операционке переполнялось Баги вообще не связанны с выполнением потока и проверки его действия.      Баг был в неверной работе с массивом из-за того что я не учёл одно редкое исключение, ну да ладно суть темы не в этом .    Цитата(Voxifer @  14.12.2009,  00:57 ) Сомнительно как-то. Теретически - максимальное число хендлов 65536, практически - HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota (10000). Сомневаюсь, что даже в 1000 потоках можно было бы открыть и держать десятку хендлов. Честно признаться на пользовательской ОС эффекта больше чем от 100 даже и не чувствуешь, а вот на сервере уже другое дело ...  Цитата(dumb @  14.12.2009,  05:25 ) при создании таймера вызывается AllocateHWnd, которая ни разу не thread-safe Ну это не самое страшное. Цитата(Демо @  14.12.2009,  10:00 ) Проблему без кода вряд ли можно понять. Скорее всего реализация с ошибкой, которая проявляется при недостатке ресурсов (процессора, памяти, например). Физической проблемы нету, есть только психологическая. Собственно я тему хотел посвятить обсуждению способов таймаутинга потоков. Цитата(dumb @  16.12.2009,  01:55 ) http://qc.embarcadero.com/wc/qcmain.aspx/qcmain.aspx?d=47559 Вот за эту сцылку вери биг сенькс, нашёл неплохую альтернативу в виде таймера DSiWin32 Добавлено через 9 минут и 15 секунд Поскольку тема пошла немного не в том русле в котором я ожидал, то вот на всякий случай для страждущих две неплохие альтернативы таймеров которым можно ~доверять~  http://17slon.com/gp/gp/files/dsiwin32.zip ну и конечно же ics-овский в составе дистрибутива ICS-V7 (http://www.overbyte.be )

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)