Войти
ПрограммированиеФорумОбщее

Модели многопоточности, или "Прощайте дедлоки" (комментарии) (3 стр)

Страницы: 1 2 3
#30
20:31, 30 дек. 2011

это не отвечает на вопрос - что такое игровой цикл в такой системе, и как мы можем реализовывать разный фиксед таймстеп для разных систем


#31
20:53, 30 дек. 2011

Mr F
То был коммент на 0-й пост. По поводу игровых циклов, схема по ссылке на гамасутру мне не кажется хорошей, возможно в каких то условия так сделать проще, но я бы подкрадывался с другой стороны. Таймингов там нет by design если я всех верно понял, физика может сделать ~10 апдейтов пока рендер застрял и наоборот. Если ничего ни как не параллелиться (или не хочется, не можется) на более низком уровне то наверно как быстрая и простая оптимизация годится.

#32
3:04, 31 дек. 2011

для начала можно начать с чтения вот этих статей:
http://drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=215900465
http://drdobbs.com/parallel/216500409
если будут проблемы с доступом к статьям - отключите куки (например включив анонимный режим просмотра в браузере)

#33
3:50, 31 дек. 2011
Изображение
Прошло более 7 месяцев
#34
16:20, 25 авг. 2012

По таскам мне понравился подход, изображенный здесь (1 отрисовка - 1 обновление физики,звука,анимации,ИИ):
Designing the Framework of a Parallel Game Engine (3.2.1. Task Manager)
У себя правда до ума не довёл.
Рендер графики привязывался к потоку в котором был создан контекст(GL), и представлял собой несколько тасков на кадр(1 таск - 1 RenderTarget[экран, текстура]).
А таск инпута привязывался к главному потоку.
На события логики пришлось всё остальное лочить...

#35
15:03, 29 авг. 2012

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

Главный поток - считывает из A и записывает в B
Любой из других тредов - считывает из B и пишет в A

A и B - это те 2 ячейки памяти в "любом другом треде", коих тысячи
Главный поток будет обходить все эти потоки и их ячейки циклом, раздавать таким образом задачи через B и принимать их через A.
Не надо никаких локов и лохов, светофоров и шлагбаумов.
Надеюсь, эту методику уже давно изобрели, и все ей спокойно пользуются.

Ges
Сам думал о такой схеме :)

#36
12:45, 30 авг. 2012

LifeKILLED
> По поводу общей памяти и дедлохов.
> Неплохая идея - выделить каждому процессу по 2 ячейки памяти под входящую и
> исходящую команду.
> В каждую из этих ячеек сможет записывать или считать команду только один поток,
> например:
> Главный поток - считывает из A и записывает в B
> Любой из других тредов - считывает из B и пишет в A
> A и B - это те 2 ячейки памяти в "любом другом треде", коих тысячи
> Главный поток будет обходить все эти потоки и их ячейки циклом, раздавать таким
> образом задачи через B и принимать их через A.
> Не надо никаких локов и лохов, светофоров и шлагбаумов.
> Надеюсь, эту методику уже давно изобрели, и все ей спокойно пользуются.
Низя так делать. Поток 1 может начать читать из А в тот момент, когда поток 2 записал туда только половину данных. Значит нам нужен флаг "готовности данных". А это по сути и будет тем же самым локом.
Кстати, тут писали, что асинхронный обмен - та же общая память, разбитая на много маленьких кусков. Да, на низком уровне очень похоже. Но на уровня языка этого нет. Вся фишка в том, что в эрланге нет "запросов" на данные к определённому потоку. Поток может только ждать данные, причём разные и сразу от нескольких потоков. Да, его можно заставить "ждать" данные от одного потока специально подобранным шаблоном, типа {only_this_pid, Data}, и это может вызвать дедлок. Но такие ситуации хорошо видны и легко отлавливаются/исправляются.

#37
21:43, 30 авг. 2012

>> Поток 1 может начать читать из А в тот момент, когда поток 2 записал туда только половину данных
Я имел в виду один байт, как код команды, который ставится после формирования данных для передачи. А уже сформированные данные (текстовая ссылка, массив данных) читать из объекта данные потока... Смысл в том, что для каждого потока используются отдельные ячейки для обмена командами с главным менеджером, и ничего общего у разных потоков нет. Никто никого не станет ждать (ну не готов запрос, менеджер переходит к другому потоку, и так по кругу)

#38
12:30, 31 авг. 2012

LifeKILLED
Так эрланг так и работает. Формируешь сообщение, отсылаешь в общий менеджер когда оно полностью готово. А менеджер просто пихает его в нужный почтовый ящик. Потом принимающий процесс просто смотрит свой "почтовый ящик" (байт команды в вашем примере) и если там что-то есть и это что-то ему подходит - забирает. Только идея развита ещё дальше - если в ящике что-то есть, но принимающему потоку не нужно - оно там просто висит и ждёт, не затираясь новыми сообщениями. А "нужное" для себя сообщение поток выбирает из ящика по шаблону, т.е. очереди сообщений нет, почтовый ящик как мини база данных с выборкой значений по одному.

#39
20:24, 31 авг. 2012

botbot
Ну вот, значит, все-таки додумались )

#40
20:54, 8 янв. 2013

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

#41
21:16, 8 янв. 2013

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

Страницы: 1 2 3
ПрограммированиеФорумОбщее

Тема в архиве.