В моей программе создается много потоков...

← →
ProstoMan (2004-06-28 17:49) [0]

...насколько это является «плохим тоном»?

Например, я написал небольшую игрушку-стрелялку, где после каждого выстрела, создается новый поток (для каждой пули), поток этот управляет скоростью пули, рисует ее на канве и т.д. При попадании пули в какой-нибудь объект, этот поток естественно прекращает существовать. Так что всего их может создаваться максимум порядка 20.
В данном случае, я не нашел другого решения, но вообще как вы считаете, насколько это плохо (если вообще плохо)?

← →
VID © (2004-06-28 17:55) [1]

Ну... если совсем дело хреново, то хотя бы не убивай каждый поток, когда пуля долетит, а делай ему Suspend. а при выстреле новой пули, по-новой инициилизируй переменные потока и делай resume.

← →
ProstoMan (2004-06-28 17:59) [2]

> VID © (28.06.04 17:55) [1]

Так а какая разница?

Вообще, я спрашиваю, является ли это «плохим тоном». А пример с игрой, это просто пример, тест, я написал ее просто от нечего делать, и стало интересно.

← →
ProstoMan (2004-06-28 18:01) [3]

Ведь даже все эти 20 потоков (может и чуть больше, может меньше), при работе, не загружают систему, там хоть и ведутся какие-то расчеты, но все же это никак не влияет на работу оси…

← →
VID © (2004-06-28 18:02) [4]

разница в том что на создание потока у ОС уходит больше времени чем на его Resume. А т.к. пули в играх летят щедро то "на этом можно сэкономить"

← →
Тимохов © (2004-06-28 18:03) [5]

> Так а какая разница?

создание/убийство потока по стравнению с приостановкой потока (или посаживанием его на ожидаение некого события) жутко ресурсоемкая опеация. Я дома проверял - если не ошиюась первое раз в 100 медленнее (если не больше). Это плохой тон, точно.

> поток этот управляет скоростью пули, рисует ее на канве
> и т.д

если у вас поток рисует на канве, то это очень плохой тон, т.к. постоянные ошибки av достанут пользователя. Если же вы рисуете через synchronize, то реально рисует главные поток, т.е. никакой выгоды от потоков :)))

← →
Тимохов © (2004-06-28 18:04) [6]

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

← →
panov © (2004-06-28 18:04) [7]

если у вас поток рисует на канве, то это очень плохой тон, т.к. постоянные ошибки av достанут пользователя.

Почему будет AV?

← →
Andryk © (2004-06-28 18:05) [8]

Гм. Ну а зачем создавать для каждой пули свой поток, если можно обойтись одним потоком и колекцией записей или объектов пуль?

← →
Тимохов © (2004-06-28 18:05) [9]

> Почему будет AV?

без syncronize?
вы пробовали?
я в общем то да, когда изучал влияние synchrnize
результат был жутковатый: иногда с работает, иногда нет...

← →
panov © (2004-06-28 18:08) [10]

>Тимохов © (28.06.04 18:05) [9]

Это смотря как отрисовывать.
Я рисовал в отдельном потоке на канве - все работало.
Конечно, это не очень хороший метод...

← →
Тимохов © (2004-06-28 18:11) [11]

> Это смотря как отрисовывать.

согласен. вообще говоря, когда я разбирался с тем, почему иногда бывает, иногда нет ошибка я пришел к выводу, что все-таки это можно делать, но очень осторожно и с пониманием дела - действительно winapi же нормально работает в многопоточности. Просто надо уметь обходить ограничения vcl. И вообще, имхо игры иначе надо писать. :)))

Это все ИМХО

← →
ProstoMan (2004-06-28 18:12) [12]

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

Ладно, я так понял лучше будет не создавать новый потоки каждый раз, а просто приостанавливать их…

Да и лучше попытаюсь как-нибудь уложить все в один.

← →
Тимохов © (2004-06-28 18:14) [13]

лучше в один :)

← →
VID © (2004-06-28 18:18) [14]

Тимохов © (28.06.04 18:14) [13]

лучше в один :)

В основной ;))

← →
Тимохов © (2004-06-28 18:22) [15]

> VID © (28.06.04 18:18) [14]

почему бы и нет :)

← →
Mim1 © (2004-06-28 18:45) [16]

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

← →
Knight © (2004-06-28 20:09) [17]

Раз где-то пробовал поиск файлов сделать через потоки... т.е. создаётся поток поиска, которому передаётся параметроми где искать, что искать и куда передавать результаты если что-то найдено. Он начинает просматривать каталог если находит нужный файл скидывает в результат, если наталкивается на папку, то в неё запузыривается новый поток... и т.д. Всё работало... количество потоков доходило до нескольких тысяч, но скорости это особенно не прибавило... может правда надо было не создавать и уничтожать, а просто останавливать и загонять в свободные новые данные поиска, а после уничтожать все разом... :)

← →
panov © (2004-06-28 20:16) [18]

>Knight © (28.06.04 20:09) [17]

Нет, надо было количество потоков ограничить.

← →
raidan © (2004-06-28 20:16) [19]

А скорость особо и не прибавится...
Винчестер - штука тормозная :(

← →
TUser © (2004-06-28 20:30) [20]

Кто-то тут создавал 2200 потоков :)
В данном случае, конечно, отдельный пток для кажждой пули не нужен.

← →
Anatoly Podgoretsky © (2004-06-28 20:30) [21]

Knight © (28.06.04 20:09) [17]
работа с дисками в птоках приводит к серьезному замедлению, коловки начинают дергаться туда-сюда. Потоки не для ускорения, а для паралельного выполнения, в ущерб скорости.

← →
VMcL © (2004-06-28 20:33) [22]

>>Mim1 © (28.06.04 18:45) [16]

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

Ну это уже от кода нити зависит. Если сделать нормальную синхронизацию по времени (хотя бы через даже через GetTickCount), то все будет более или менее нормально.

P.S. Зачем поток на каждую пулю МНЕ всё равно непонятно.

← →
Knight © (2004-06-28 20:42) [23]

> panov © (28.06.04 20:16)
> Нет, надо было количество потоков ограничить.

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

> [19] raidan © (28.06.04 20:16)
> А скорость особо и не прибавится...
> Винчестер - штука тормозная :(

Ну я думал, что компы щас быстрые, поэтому и попробовал сделать, чтобы пока один поток доискивает в одной папке другие уже ищут в других, чтобы они как муравьи, разбежались и принесли всё что надо :)

← →
Knight © (2004-06-28 20:52) [24]

> [21] Anatoly Podgoretsky © (28.06.04 20:30)
> работа с дисками в птоках приводит к серьезному замедлению,
> коловки начинают дергаться туда-сюда.

Во-во... когда я эту прогу на 80-ти гиговый винт натравил и прислушался... мне его аж жалко стало... готовился к худшему, что умрёт молодым и красивым, но ничего выжил :)

и как его не разорвало?

> [9] Тимохов © (28.06.04 18:05)
Пробовали, Дим а критические секции для чего нам даны? А семафоры?
Это вообще долгий разговор, так как синхронизация потоков сама по себе увлекательная задача, при чем когда не тупая синхронизация типа - этот отработал пошел следующий а с ветвлением результата и передачей результата между несколькими потоками...
К примеру (люблю приводить этот пример :)
Дано 16 потоков:
все потоки обрабатывают по некому своему алгоритму данные (к примеру шифруем) но только один из потоков работает с правильными данными а остальные с левыми. В любой случайный момент времени потоки перебрасывают между собой эти данные причем рандомно.
Каждый поток пожет выделить некую область памяти, получить к ней доступ и модифицировать ее. Заранее не извесно кто из них будет отвечать за правильный участок данных. Результат работы алгоритма - некий хэш который прогоняется через электронный ключ типа Guardian или Hasp...
Вот такие чтучки писать действительно увлекательно :)

← →
ProstoMan (2004-06-28 21:41) [27]

А каждой пули нужен был свой поток, потому, что он делал свои расчеты, свои для каждой пули, а главная причина - скорость я замедлял с помощью sleep. Разная скорость у всех пуль была. Да и вообще так удобней.

>Knight © (28.06.04 20:42) [23]
>Anatoly Podgoretsky © (28.06.04 20:30) [21]

На современных ПК достаточно большой объем RAM, и операционная система весьма неплохо кэширует страницы. Таблица расположения файлов не является исключением, она тоже кэшируется.

А то, какое количество потоков выбрат для оптимального поиска файлов, тут срзу ничего н могу сказать-)

>ProstoMan (28.06.04 21:41) [27]
Мне кажется, что в твоем случае вполне нормально использовать потоки. По крайней мере, основной поток реагирует на действия пользователя без заминок.

Не силен в написании игр, но по-моему - 20 потоков это, как говорится не о чем.

← →
ProstoMan (2004-06-28 21:52) [31]

В смысле, когда в программе создается 20 потоков - это не повод думать, что потоков много.

> [28] panov © (28.06.04 21:44)

Если файлы искать, то да... но я забыл добавить, что на 80-сятнике я тестил поиск по контенту... а там где про "молодого и красивого" опечатка в слове "умру" - это я о себе :)

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

В моей программе создается много потоков... Найти похожие ветки