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

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

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

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

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

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

Ну а по заданному вопросу... Курить ВинАПИ и как-то перепроектировать логику работы проги. Ибо в диспетчере задач Виндов можно увидеть, что все нужды операционки (в т.ч. и сетевые) укладываются в сотни две-три потоков.

Сомнительно как-то. Теретически - максимальное число хендлов 65536, практически - HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota (10000). Сомневаюсь, что даже в 1000 потоках можно было бы открыть и держать десятку хендлов.
Не зная твоего кода, можно лишь предполагать, что, возможно, ты не учел низкоприоритетность таймеров, что на фоне высокой загрузки приложения могло отозваться пропуском сообщений таймеров. Ну и есть, конечно, подозрения на твоё "принудительное" завершение потока, может быть оно проходило без освобождения ресурсов.

В любом случае, использовать низкоточный системный таймер в таймаутах потоков при условии высокой нагрузки, мне кажется, не есть айс. Гораздо проще сделать Sleep(50) в цикле N раз, где  N = таймаут/50. Ну или использовать высокоточный системный таймер. По крайней мере, я бы с этого начал, если бы у меня была аналогичная задача...

при создании таймера вызывается AllocateHWnd, которая ни разу не thread-safe

ps. хотя, возможно в свежих версиях дельфей этот момент исправлен 

Поясни плиз не "thread-safe"-вость. В чём она здесь заключается?

RA, 

Проблему без кода вряд ли можно понять.
Скорее всего реализация с ошибкой, которая проявляется при недостатке ресурсов (процессора, памяти, например).

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

  Это при использовании компонента? Я имею ввиду, может таймер создается в каждый в своем потоке при помощи CreateTimer. 

Да и с TTimer никаких проблем нет. Прекрасно будет работать в потоках.

http://qc.embarcadero.com/wc/qcmain.aspx/qcmain.aspx?d=47559

как и всегда в таких случаях - до определенного момента. 

dumb, 

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

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

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

  Поиск по исходникам показал что вызов "Classes.AllocateHWnd" присутствует 5 раз, так что критическая секция для таймера не спасет. 

В TTimer?

Alexeis, 

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

  В том то и дело что нет, т.е. теоретически вызов Classes.AllocateHWnd из основного потока и вызов из конструктора таймера в отдельном потоке могут совпасть во времени.
  

  Что значит "генетический материал"? Перекомпилить VCL?

Ну да. Classes.pas.

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

Баги вообще не связанны с выполнением потока и проверки его действия.     
Баг был в неверной работе с массивом из-за того что я не учёл одно редкое исключение, ну да ладно суть темы не в этом .   




Честно признаться на пользовательской ОС эффекта больше чем от 100 даже и не чувствуешь, а вот на сервере уже другое дело ... 



Ну это не самое страшное.



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



Вот за эту сцылку вери биг сенькс, нашёл неплохую альтернативу в виде таймера DSiWin32

Добавлено через 9 минут и 15 секунд
Поскольку тема пошла немного не в том русле в котором я ожидал, то вот на всякий случай для страждущих две неплохие альтернативы таймеров которым можно ~доверять~ 


http://17slon.com/gp/gp/files/dsiwin32.zip

ну и конечно же ics-овский в составе дистрибутива ICS-V7 (http://www.overbyte.be )