Comments 13
Спасибо, очень ждал продолжения :)
UFO just landed and posted this here
Наконец-то дождался :)
Тебе вообще отдельное спасибо. Jazzis нашел в первой части много ошибок, за что я ему очень благодарен.
Поток рендеринга backend интерфейса (Отправка команд GPU)
Поток игровой логики и рендеринга frontend интерфейса
задание не должно длиться не более чем несколько 100 000 тактов
Последний являются предпочтительным, так как позволяет двигателю сохранять фокусировку CPU.
Эти три механизма реализации
разделить списки заданий на несколько секций, к каждому из которых обращается только один поток
Рендер frontend-a
Рендер backend-a
Если поток не может «заблокировать» JobList, она падает в RUN_STALLED режим.
Сигналы используется
Реализует получение указанного объекта критической секции.
Чем переводили то?
tr.frontEndJobList->Submit();
tr.frontEndJobList->Wait();
Смахивает на типовую ошибку синхронного программирования. Что будет, если задание выполнится раньше, чем управление текущего треда перейдет к Wait()? Только не надо говорить что «задания подбираются таким образом, чтобы текущий тред успел войти в ожидание» %)
В TPL, например, Wait на завершённом Task-е возвращает управление сразу. Подозреваю, что здесь при завершённом таске/пустой очереди происходит то же самое.
Ну, там так и написано, читай
:)
задание должно длиться по крайней мере пару 1000 тактов
:)
Это относится к решению вопроса о том, стоит ли вообще задание выполнять асинхронно через планировщик, или проще в текущем потоке всё обсчитать.
Ну и как это оценить — ведь пишем на с++, мы заранее не знаем как развернется код в машинные команды да и вообще одна и та же команда на разных моделях процессоров (да вполне вероятно что на разных степингах) может занимать разное количество тактов.
Sign up to leave a comment.
Doom 3 BFG — обзор исходного кода: Многопоточность (часть 2 из 4)