Чтобы ответить на первый вопрос, я не знаю никаких алгоритмов моделирования дискретных событий (DES), которым не нужна глобальная очередь событий. Возможна иерархия очередей событий, в которой каждая очередь событий представлена в своей родительской очереди событий как событие (соответствующее времени следующего события). Если новое событие добавляется в очередь событий таким образом, что оно становится следующим событием в очереди, то очередь событий необходимо перепланировать в родительском элементе, чтобы сохранить порядок выполнения событий. Однако в конечном итоге вы все равно сведетесь к одной глобальной очереди событий, которая является родительской для всех остальных в иерархии и которая отправляет каждое событие.
В качестве альтернативы вы можете отказаться от DES и использовать что-то более похожее на программируемый логический контроллер (ПЛК), который переоценивает состояние всей сети через каждый небольшой интервал времени. Однако, как правило, это было бы намного медленнее (возможно, оно даже не работало бы так же быстро, как в режиме реального времени), потому что большую часть времени ему было бы нечего делать. Если вы выберете слишком большое приращение времени, симуляция может потерять точность.
Самый простой ответ на второй пункт заключается в том, что, в конечном счете, насколько мне известно, без глобальной очереди событий обойтись невозможно. Каждое событие моделирования должно выполняться в нужное время, и, поскольку время не может идти вспять, порядок, в котором отправляются события, имеет значение. Текущее время моделирования определяется временем выполнения текущего события. Если у вас есть отдельные очереди событий, у вас также есть отдельные часы, что, мягко говоря, сильно запутывает.
В вашем случае, если ваши подсети полностью независимы, вы можете моделировать каждую подсеть по отдельности. Однако если состояние одной подсети влияет на состояние всей сети, а состояние всей сети влияет на состояние каждой подсети, то, поскольку на событие влияют предшествующие ему события, могут влиять только те события, которые следовать, но не может влиять на то, что ему предшествовало — вы должны моделировать всю сеть с глобальной очередью событий.
Если вас это утешит, настоящая симуляция DES не выполняет никакой обработки между событиями (кроме определения следующего события), поэтому в одной подсети не должно быть ненужной обработки, если все действия происходят в другой.
Наконец, функциональное реактивное программирование (FRP) абсолютно полезно в контексте DES. Действительно, теперь я пишу о многих своих симуляциях DES на Scala, используя этот подход.
Надеюсь, это поможет!
ОБНОВЛЕНИЕ: после написания вышеизложенного я использовал Sodium< /em> (отличная библиотека FRP, на которую ссылается OP в комментариях ниже) и может добавить некоторые дополнительные пояснения: Sodium предоставляет средства для подписки на события и для выполнения действий при возникновении этих событий. Однако здесь я использую термин событие в общем смысле, например нажатие кнопки пользователем в графическом интерфейсе, прибытие сетевого пакета и т. д. Другими словами, события не обязательно являются событиями симуляции.
Вы по-прежнему можете использовать Sodium или любую другую библиотеку FRP как часть моделирования, чтобы подписаться на события моделирования и выполнять действия, когда они происходят; однако эти инструменты, как правило, не имеют встроенной поддержки моделирования, поэтому вы должны включить механизм моделирования в качестве источника событий моделирования, точно так же, как GUI включается в качестве источника пользовательских события взаимодействия. Именно в этом движке должна находиться глобальная очередь событий.
Между прочим, если вы пытаетесь выполнить параллельное или распределенное выполнение имитационной модели, все становится значительно сложнее. В этих ситуациях у вас есть несколько очередей событий, но они должны быть синхронизированы (чтобы выглядела одна очередь). Двумя основными подходами являются консервативная синхронизация и оптимистическая синхронизация.
person
Mike Allen
schedule
10.03.2014
