A-tit indd

Паттерны программирования игр
— Паттерны уменьшения связанности
313
Этот паттерн отделяет отправителя запроса от време-
ни обработки запроса, но если вы обращаетесь с очере-
дью как с живой структурой данных, с которой играете, 
задержка между формированием запроса и его обра-
боткой может заметно повлиять на поведение. Перед 
использованием паттерна убедитесь, что вас все устра-
ивает.
Разделение потоков
И наконец, самая большая проблема. При нашей син-
хронной реализации аудио API, в каком бы потоке 
ни был вызван 
playSound()
, обрабатываться он будет 
в том же потоке. А мы явно хотели чего-то другого.
При сегодняшней многоядерной архитектуре ап-
паратного обеспечения вы сможете выжать максимум 
из процессора, только если будете иметь больше одного 
потока. Есть невероятное количество способов распре-
делить код между потоками, но самый распространен-
ный — поместить каждую область игры (аудио, ренде-
ринг, ИИ и так далее) в отдельный поток.
Мы можем использовать разделение на потоки, по-
скольку у нас есть три ключевые предпосылки.
1. Код, отправляющий запрос на воспроизведение зву-
ка, не связан с кодом, который его воспроизводит.
2. У нас есть очередь для их взаимодействия.
3. Очередь инкапсулирована от остальной программы.
Нам остается поместить взамодействующие с очере-
дью методы, 
playSound()
и 
update()
, в изолирован-
ные потоки. В обычной ситуации я привел бы здесь пару 
фрагментов кода, но поскольку моя книга об архитекту-
ре, не хочу углубляться в детали реализации конкретно-
го API или механизма блокировки.
На более высоком уровне рассмотрения нам просто 
надо убедиться, что доступ к очереди не осуществля-
ется конкурентно. Поскольку функций у 
playSound()
не очень много — обычно просто присвоение значений 
Линейный участок про-
граммы всегда выполня-
ется в одном ядре. Если 
вы не применяете раз-
деление на потоки, 
то даже использование 
модного сейчас асин-
хронного стиля про-
граммирования в луч-
шем случае нагрузит 
только одно ядро, что 
является только частич-
ным использованием 
возможностей процес-
сора.
Программисты, со-
здающие серверное ПО,