Ой, не знаю, много раз читал. Но так и ничего не понял. Всегда использовал многопоточность, когда для однотипных наборов данных можно реализовать код, который будет обрабатывать эти данные независимо в разных потоках. Это как кирпичи на разных стенах класть. Но если класть их параллельно через метр, можно столкнуться с проблемой не стыковки.
Цитата:
Однако, вместо того, чтобы каждая система обращалась к общим данным, например, за координатами положения или ориентации объекта, каждой системе следует предоставить свою копию данных. Это устранит взаимную зависимость разных частей движка от данных. Уведомления об изменениях, внесенных какой-либо частью в общие данные, передаются менеджеру состояний (State Manager), который помещает все изменения в очередь – это называется режимом обмена сообщениями (messaging). После того, как разные системы завершили свой очередной цикл выполнения, они обрабатывают сообщения от менеджера состояний, в соответствие с которыми обновляют свои внутренние структуры данных. Использование подобного механизма позволяет значительно сократить накладные затраты на синхронизацию, обеспечивая независимую работу систем.
Мне кажется, может быть ситуация "бутылочного горла" когда затраты на обработку State Manager будут выше, чем плюсы от многопоточной обработки.
Как правило, каждый этап работы движка зависит от предыдущего, поэтому не понятно как можно можно их распараллелить...