Некоторые замечания о неверном использовании регистратора очереди
Начинающие изучение GPSS могут составить неверное представление об использовании регистратора очереди. Два наиболее часто встречающихся ошибочных представления мы прокомментируем ниже.
Первой ошибкой является то, что многие считают, будто регистраторы очереди необходимо использовать в модели всюду, где могут возникать очереди. Часто думают, что если регистратор очереди не записан, то не обеспечивается возможность ожидания обслуживания. Это неверно. Использование регистратора очереди совершенно необязательно. При использовании регистратора интерпретатор собирает статистику об ожидании; если регистратор не используется, статистика не собирается, но всюду, где должно возникать ожидание, оно возникает. Например, на рис. 8.2 независимо от того, находится ли блок SEIZЕ между парой QUEUE - DEPART или нет, транзакт не войдет в блок SEIZЕ, если прибор JОЕ занят. Ожидание является следствием состояния прибора, а не следствием использования регистратора очереди.
Во многих случаях, даже если известно, что в определенных местах системы возникают очереди, разработчик предпочитает не использовать регистратор очереди. Если в планы не входит обработка статистических данных об очередях, то лучше не собирать статистику. Это сэкономит время, расходуемое на моделирование.
Для иллюстрации на рис. 8.4 изображена система, в которой в шести различных местах могут возникать очереди. Разработчик модели может принять решение собрать статистику во всех шести местах или не собирать ее вовсе; может принять решение собирать статистику в некоторых из этих мест модели или, например, собирать статистику в точках 2, 4, 5 и 6 и не собирать ее в точках 1 и 3.В данной книге дано много примеров, где в местах возникновения очереди статистика об очереди не собирается. В четвертом и пятом примерах этой главы приведены такие случаи.
Второй общей ошибкой, касающейся использования регистраторов очереди, является мнение, будто транзакт не является элементом очереди, если он не находится в блоке QUEUE. Это неверно.
Транзакт просто отмечает факт своего присутствия в очереди входом в блок, где осуществляется привязка к очереди по имени и времени входа в очередь. Независимо от того, остается транзакт в блоке QUEUE
или нет, он остается элементом очереди до тех пор, пока не войдет в блок DEРАRТ соответствующей очереди. В зависимости от того, каким образом построена модель, транзакт в общем случае может некоторое время находиться в различных частях модели после того, как он покинет блок QUEUЕ, и прежде, чем он войдет в соответствующий ему блок DEРАRТ. Выше мы сделали предположение, что транзакт может являться элементом более чем одной очереди. Это вовсе не так уж странно, как может показаться на первый взгляд. Можно без труда придумать ситуацию, когда люди одновременно стоят в двух или даже более очередях. Здесь следует отметить, что находиться в очереди вовсе не значит физически в ней присутствовать. Представим себе, например, случай прихода в мясной магазин покупательницы, которой приписан номер в момент входа в магазин. Если покупательница видит, что ее номер еще не дошел, она может пройти в другой магазин, например в бакалейный, стать там в очередь, обслужиться, снова вернуться в мясной магазин и ждать своей очереди. С точки зрения нахождения в очереди, она была в мясном магазине все время, хотя на самом деле она побывала и в бакалейном. В GPSS транзакт не может присутствовать одновременно более чем в пяти очередях. Если транзакт уже находится в пяти очередях и делает попытку присоединиться к шестой, то печатается предупреждающее сообщение с номером 853 . Причиной ограничения именно пятью очередями является наличие только пяти полей записи для имени очереди при привязке транзакта к очереди и пяти полей для записи времени присоединения к очереди. При рассмотрении второго примера моделирования в этой главе приведена модель на GPSS , в которой транзакты одновременно присутствуют в двух различных очередях.
