![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблемы многопоточности [D7, Win95/98, WinME, NT4, Win2k, WinXP]
C@es@r © (2004-01-25 12:16:00)Ситуация: Программа в потоке посылает и передает некоторую инф-цию в\из сети. Один поток - простая операция послал-получил. Дело в том, что написано все ок и при небольшом кол-ве потоков (скажем 30) все работает отлично. Но при установлении программы на дид и использовании кажем 500-1000 потоков одновременно могут появляться различные исключения! Я думаю это связано с тем что очень часто создаются\удаляются потоки. И думал, чтобы уменьшить кол-во создания\удаления потоков, модифицировать свой простой поток в более сложный (чтоб прямо в нем загружалась новая инф-ция, а не из основного потока). Дак вот если возможно, подскажите истинные мастера, я прав или нет? Стоит ли это все делать, и каким образом создать поток наиболее защищенный от глюков?
circul (2004-01-26 17:48:00) [1]Удалено модератором
Polevi (2004-01-26 17:24:00) [2]>Digitman © (26.01.04 14:25) [8]
какие сложности ты имеешь в виду ? statefull объекты ?
Verg (2004-01-26 16:32:00) [3]
> csr_ (26.01.04 15:55) [12]
> Дак я проверил сто раз - нет и не может быть никакой ошибки.
> Все правильно! А что мне еще думать остается?
А нам что думать? Искать черную кошку в темной комнате?
Упрости свой код, выдели этот эффект, так сказать, в чистом виде. Покажи его. Дай способ и нам воспроизвести ошибку.
Это нормальная практика заявлять об ошибках в готовых продуктах (ОС в данном случае).
Иначе - пустой звук.
Вот не встречал я, например, таких "глюков". И что, как мне тебе, нА слово верить?
Digitman (2004-01-26 16:06:00) [4]
> Дак я проверил сто раз
прелюбопытно, как ты "проверял" ..
csr_ (2004-01-26 15:55:00) [5]Дак я проверил сто раз - нет и не может быть никакой ошибки. Все правильно! А что мне еще думать остается?
Verg (2004-01-26 15:44:00) [6]В любом случае искать ошибку надо сначала в своей программе, а не сваливать на "глючный масдай".
А то нехорошие ассоциации, знаете ли, с танцором. Как сказал один мой приятель: "Плохому программеру всегда Виндовз мешает".....
Digitman (2004-01-26 15:38:00) [7]
> C@es@r
> могут появляться различные исключения
мы тут догадываться должны. что за исключения у тебя приключаются ?
C@es@r (2004-01-26 15:31:00) [8]Спасибо господа за ответы.
2 Dred2k © : Метод Synchronize я использую только при обновления интерфейса программы.
2 Polevi © : Ты думаешь если еще кроме основных потоков которые в секунду раз 10 создаются и уничтожаются создавать еще потоки, то меньше глючить будет?
Digitman (2004-01-26 14:25:00) [9]
> Polevi © (26.01.04 12:15) [6]
без сомнения - схема замечательная, но при использовании ПВ как контроллера OLE/COM-автоматизации может возникнуть ряд ощутимых сложностей в ситуации, если задействуются соотв.серверы автоматизации с ThreadingModel = Apartmemt
Polevi (2004-01-26 12:18:00) [10]PS
Для анализа загруженоости можно использовать доп. поток, котоый будет следить за очередью запросов. Если время ожидания обработки запроса первышает некое значение - добавляем поток (или сразу несколько) в пул
Polevi (2004-01-26 12:15:00) [11]Нужно разнести поток транспорта (ПТ) и потоки выполнения (ПВ)
При старте создаешь один ПТ и несколько ПВ
ПТ ожидает запрос от клиента, и объект готовности данных в очереди ответов
ПТ получает запрос, помещает его в некую очередь и взводит объект синхронизации (к примеру семафор) который ожидают ПВ
Первый свободный ПВ выбирает запрос из очереди, обрабатывает, помещает результат в очередь ответов и взводит объект наличия ответа в очереди
ТП просыпается и отправляет ответ клиенту
Анализируя загруженность потоков выполнения можно диначиски добавлять/удалять их из пула ПВ
У меня работает подобная схема, при колве клиентов около 200, колво ПВ в пуле редко превышает 10, хотя это конечно зависит от активности клиентов и "тяжести" запросов
Verg (2004-01-26 11:50:00) [12]
> Я думаю это связано с тем что очень часто создаются\удаляются
> потоки.
Нет никаких оснований для такого диагноза. Скорее всего есть погрешности во взоимодействии потоков с ОС или друг с другом.
Другое дело, что создание потока вообще для ОС (и не только в Windows) - это так сказать "немалое гружево". Так что я, например, предпочитаю иметь пул (кэш) потоков, куда они переводятся после завершения своей работы и уничтожаются там только по истечении времени "простоя".
Когда же появляется необходимость в новом потоке, сначала проверяется этот пул, и, если там есть "спящий" поток, то его и использую. Как бы бужу его, переводя в список работающих потоков, передав ему новые данные (новый сокет, например, после accept). Производительность, надо сказать, сильно повышается.
Digitman (2004-01-26 08:29:00) [13]приведи код поточной ф-ции
Dred2k (2004-01-25 14:54:00) [14]> synchronize()
На мой взгляд, это не совсем оправданно. Ты что-нить рисуешь при этом? Если нет, то synchronize сводит "эффект потока" на нет - выполнение будет произведено фактически в рамках главного потока
процесса.
> Слишком частое создание\уничтожение потоков
Думаю, что винда и не знает что такое "слишком частое". Дело в чем-то другом.
> Это нормально?
Навскидку не скажешь. Кроме того, всегда можно наделать вполне банальных ошибок, вроде и не связанных с потоками...
Если тебе нужно их так часто создавать и убивать - совсем ли корректна постановка задачи? Оправданна ли такая реализация?
C@es@r (2004-01-25 14:22:00) [15]Нет-нет. Я это хорошо проверил: всегда юзаю synchronize() и кое-где критические секции. Если бы код потока не был синхронизирован, то уже при 5 потоках было бы банальное "молчаливое вылетание" программы...
Вопрос вот в чем: Слишком частое создание\уничтожение потоков (в то же время абсолютно корректное в плане написания кода) может ли вызвать ошибки? Возможно Билли что-то с этим не додумал?! Например если в секунду создается и убивается около 10 потоков (одного и того же класса). Это нормально?
Dred2k (2004-01-25 13:30:00) [16]На первый взгляд дело тут в межпоточном взаимодействии - разные потоки обращаются к одним и тем же ресурсам, причем не только для чтения. При небольшом кол-ве потоков и, соответственно, при относительно невысокой интенсивности операций, коллизии могут и не возникать.
Советую обратить внимание на механизмы синхронизации - критические секции, эвенты, ...