"Первый пример использования цепей текущих и будущих событий"
Рассмотрим, как интерпретатор GPSS использует цепи текущих и будущих событий на примере моделирования системы с одним прибором и очередью, представленном на рис. 13.1.
Рис. 13.1.Блок-схема для примера моделирования 2А.
Для этого надо сделать следующее:
- Определить обозначения соответствующей информации о транзактах.
- Задать распределения интервалов прихода и обслуживания транзактов.
- Ввести таблицы, показывающие временную зависимость транзактов, находящихся в цепях текущих и будущих событий.
- Пояснить действия, предпринимаемые интерпретатором, показом изменения информации о транзактах, перемещаемых в модели.
На этот раз цепь пуста. Поэтому на следующем этапе необходимо выполнить фазу коррекции таймера. В это время транзакты в цепи будущих событий в строке 8 имеют смысл, указанный в табл. 13.6. Таблица 13.6.
| Номер транзакта | Смысловое значение |
| 3 | Второй клиент стрижется |
| 4 | Третий клиент едет в парикмахерскую |
| 2 | Транзакт-таймер |
Четвертое выполнение фазы коррекции таймера (от строки 8 к строке 9). Интерпретатор продвигает время к значению 44 - времени движения транзакта (транзакта 4), стоящего первым в строке 8 цепи будущих событий. Затем он перемещает транзакт 4 из ЦБС в ранее пустую ЦТС. Следующий транзакт в ЦБС (транзакт 3) также имеет значение времени движения, равное 44. Он также перемещается в цепь текущих событий, где помещается за транзактом 4 в качестве последнего элемента внутри своего класса приоритетов. Следующий транзакт в цепи будущих событий (транзакт 2) имеет время движения, отличное от 44. Таким образом, четвертая коррекция таймера завершается. Прежде чем продолжить, давайте снова посмотрим, какой смысл придается двум транзактам, стоящим в строке 9 цепи текущих событий (табл. 13.7). Таблица 13.7. Смысловые значения транзактов в цепи текущих событий.
| Номер транзакта | Смысловое значение |
| 4 | Третий клиент только что пришел в парикмахерскую |
| 3 | Второй клиент только что закончил стрижку |
Транзакт, который прежде уже был в модели и символизировал собой первого клиента, теперь вернулся "в игру", символизируя четвертого клиента того же дня. В качестве конкретного примера одновременных событий в GPSS рассмотрим пример моделирования 2А и соответствующие состояния цепей, показанные на рис. 13.6. В строке 9 на рис.13.6 в цепи текущих событий мы видим два события, запланированных на одно и то же модельное время 44. Первым из этих событий, [4,КМР,НЕТ, 0,1], является приход клиента в парикмахерскую. Вторым из этих событий, [3,КМР,5,0,6], является завершение обслуживания клиента, находящегося в кресле парикмахера. На самом деле следующий клиент входит в дверь как раз в момент, когда обслуживаемый клиент поднимается из кресла парикмахера. Посмотрим теперь, как эта реальная ситуация моделируется в примере 2А. При просмотре цепи текущих событий интерпретатор GPSS сначала обнаруживает транзакт 4. Транзакт 4 последовательно входит в блок GENERATE, затем в блок QUEUE и должен там задержаться. Фактически, интерпретатор осуществляет вход следующего клиента в дверь и присоединяет его к очереди. Далее, продолжая просмотр цепи текущих событий, интерпретатор выбирает транзакт 3. Этот транзакт вводится в блоки RELEASE и TERMINATE, что означает "клиент уходит из парикмахерской". Здесь, следовательно, произошли два события - приход клиента и завершение обслуживания. Последовательность обработки была: приход клиента, а затем завершение обслуживания просто потому, что транзакт 4 оказался впереди транзакта 3 в цепи текущих событий. Если бы относительная последовательность этих двух событий в ЦТС оказалась инверсной, то и обработка этих событий была бы инверсной. Конечно, в этой точке система еще не окончательно изменяет свое состояние в момент модельного времени 44. Сейчас возникло условие, при котором произошло событие "перевод состояния парикмахера в положение свободно". Поскольку как часть завершения обслуживания выполняется обработка блока RELEASE, интерпретатор заново просматривает цепь текущих событий.
В результате интерпретатор снова выбирает транзакт 4, продвигая его в тот же момент модельного времени через блоки SEIZE и DEPART и вводя его в блок ADVANCE. Следовательно, произойдет событие "занятия". На этом и завершатся действия в момент времени 44. Должно быть ясно, что когда возникают временные узлы в примере моделирования 2А, то последовательность, в которой обрабатываются вовлеченные события, зависит от случая. Однако и не требуется никакого формального контроля в этой простой модели, поскольку интерпретатор заново просматривает ЦТС после обработки блока RELEASE. Если бы это было не так, модель была бы неверной, так как хотя и существовали бы в момент времени 44 ожидающий клиент и освободившийся парикмахер, никакие действия не были бы предприняты для того, чтобы клиент перешел на обслуживание к парикмахеру. Интерпретатор, следовательно, построен таким образом, что в этой модели ему безразлична последовательность возникновения одновременных событий. В примере моделирования 2А легко поменять условия таким образом, что последовательность, в которой будут записаны состояния в цепях на рис.13.6 в момент времени 44, станет небезразличной. Предположим, что прибывающий клиент решает остаться только в том случае, если он немедленно может начать обслуживаться у парикмахера, и что модель модифицируется таким образом, чтобы учесть это предположение (отметим, что мы еще не изучили способа, как это сделать). В этом случае, если приход возникнет раньше события завершения, пришедший клиент не останется на обслуживание, а если последовательность событий будет обратной, останется. При таких условиях очень важно разработать модель таким образом, чтобы в случае возникновения временных узлов завершение обслуживания всегда происходило раньше прихода заявки. Очевидно, что именно такой будет последовательность событий, если принять меры к тому, чтобы обеспечить условие расположения транзакта "завершение обслуживания" ближе к началу ЦТС, чем транзакт "приход заявки". Уже упоминалось, что относительное расположение транзактов в ЦТС определяется уровнем приоритетов.Если бы транзакт "завершение обслуживания" имел более высокий приоритет, чем транзакт "приход заявки", то имела бы место желаемая последовательность обработки событий. Позднее мы увидим, каким образом может устанавливаться уровень приоритетов для того, чтобы избежать проблем, которые возникли бы в связи с временными узлами.
