Проблемы многопоточности

← →
C@es@r (2004-01-25 12:16) [0]

Ситуация: Программа в потоке посылает и передает некоторую инф-цию в\из сети. Один поток - простая операция послал-получил. Дело в том, что написано все ок и при небольшом кол-ве потоков (скажем 30) все работает отлично. Но при установлении программы на дид и использовании кажем 500-1000 потоков одновременно могут появляться различные исключения! Я думаю это связано с тем что очень часто создаются\удаляются потоки. И думал, чтобы уменьшить кол-во создания\удаления потоков, модифицировать свой простой поток в более сложный (чтоб прямо в нем загружалась новая инф-ция, а не из основного потока). Дак вот если возможно, подскажите истинные мастера, я прав или нет? Стоит ли это все делать, и каким образом создать поток наиболее защищенный от глюков?

← →
Dred2k © (2004-01-25 13:30) [1]

На первый взгляд дело тут в межпоточном взаимодействии - разные потоки обращаются к одним и тем же ресурсам, причем не только для чтения. При небольшом кол-ве потоков и, соответственно, при относительно невысокой интенсивности операций, коллизии могут и не возникать.
Советую обратить внимание на механизмы синхронизации - критические секции, эвенты, ...

← →
C@es@r (2004-01-25 14:22) [2]

Нет-нет. Я это хорошо проверил: всегда юзаю synchronize() и кое-где критические секции. Если бы код потока не был синхронизирован, то уже при 5 потоках было бы банальное "молчаливое вылетание" программы...
Вопрос вот в чем: Слишком частое создание\уничтожение потоков (в то же время абсолютно корректное в плане написания кода) может ли вызвать ошибки? Возможно Билли что-то с этим не додумал?! Например если в секунду создается и убивается около 10 потоков (одного и того же класса). Это нормально?

← →
Dred2k © (2004-01-25 14:54) [3]

> synchronize()
На мой взгляд, это не совсем оправданно. Ты что-нить рисуешь при этом? Если нет, то synchronize сводит "эффект потока" на нет - выполнение будет произведено фактически в рамках главного потока
процесса.

> Слишком частое создание\уничтожение потоков
Думаю, что винда и не знает что такое "слишком частое". Дело в чем-то другом.

> Это нормально?
Навскидку не скажешь. Кроме того, всегда можно наделать вполне банальных ошибок, вроде и не связанных с потоками...

Если тебе нужно их так часто создавать и убивать - совсем ли корректна постановка задачи? Оправданна ли такая реализация?

← →
Digitman © (2004-01-26 08:29) [4]

приведи код поточной ф-ции

← →
Verg © (2004-01-26 11:50) [5]

> Я думаю это связано с тем что очень часто создаются\удаляются
> потоки.

Нет никаких оснований для такого диагноза. Скорее всего есть погрешности во взоимодействии потоков с ОС или друг с другом.

Другое дело, что создание потока вообще для ОС (и не только в Windows) - это так сказать "немалое гружево". Так что я, например, предпочитаю иметь пул (кэш) потоков, куда они переводятся после завершения своей работы и уничтожаются там только по истечении времени "простоя".
Когда же появляется необходимость в новом потоке, сначала проверяется этот пул, и, если там есть "спящий" поток, то его и использую. Как бы бужу его, переводя в список работающих потоков, передав ему новые данные (новый сокет, например, после accept). Производительность, надо сказать, сильно повышается.

← →
Polevi © (2004-01-26 12:15) [6]

Нужно разнести поток транспорта (ПТ) и потоки выполнения (ПВ)
При старте создаешь один ПТ и несколько ПВ
ПТ ожидает запрос от клиента, и объект готовности данных в очереди ответов

ПТ получает запрос, помещает его в некую очередь и взводит объект синхронизации (к примеру семафор) который ожидают ПВ

Первый свободный ПВ выбирает запрос из очереди, обрабатывает, помещает результат в очередь ответов и взводит объект наличия ответа в очереди

ТП просыпается и отправляет ответ клиенту

Анализируя загруженность потоков выполнения можно диначиски добавлять/удалять их из пула ПВ

У меня работает подобная схема, при колве клиентов около 200, колво ПВ в пуле редко превышает 10, хотя это конечно зависит от активности клиентов и "тяжести" запросов

← →
Polevi © (2004-01-26 12:18) [7]

PS
Для анализа загруженоости можно использовать доп. поток, котоый будет следить за очередью запросов. Если время ожидания обработки запроса первышает некое значение - добавляем поток (или сразу несколько) в пул

← →
Digitman © (2004-01-26 14:25) [8]

> Polevi © (26.01.04 12:15) [6]

без сомнения - схема замечательная, но при использовании ПВ как контроллера OLE/COM-автоматизации может возникнуть ряд ощутимых сложностей в ситуации, если задействуются соотв.серверы автоматизации с ThreadingModel = Apartmemt

← →
C@es@r (2004-01-26 15:31) [9]

Спасибо господа за ответы.
2 Dred2k © : Метод Synchronize я использую только при обновления интерфейса программы.
2 Polevi © : Ты думаешь если еще кроме основных потоков которые в секунду раз 10 создаются и уничтожаются создавать еще потоки, то меньше глючить будет?

← →
Digitman © (2004-01-26 15:38) [10]

> C@es@r

> могут появляться различные исключения

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

← →
Verg © (2004-01-26 15:44) [11]

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

А то нехорошие ассоциации, знаете ли, с танцором. Как сказал один мой приятель: "Плохому программеру всегда Виндовз мешает".....

← →
csr_ (2004-01-26 15:55) [12]

Дак я проверил сто раз - нет и не может быть никакой ошибки. Все правильно! А что мне еще думать остается?

> Дак я проверил сто раз

прелюбопытно, как ты "проверял" ..

> csr_ (26.01.04 15:55) [12]
> Дак я проверил сто раз - нет и не может быть никакой ошибки.
> Все правильно! А что мне еще думать остается?

А нам что думать? Искать черную кошку в темной комнате?

Упрости свой код, выдели этот эффект, так сказать, в чистом виде. Покажи его. Дай способ и нам воспроизвести ошибку.
Это нормальная практика заявлять об ошибках в готовых продуктах (ОС в данном случае).
Иначе - пустой звук.
Вот не встречал я, например, таких "глюков". И что, как мне тебе, нА слово верить?

Удалено модератором

Проблемы многопоточности Найти похожие ветки