7. Заключение

Эта статья предлагает структуру модуля операционной системы, который планирует ресурсы для параллельных процессов пользователей, очень похожую на представление данных, используемое в последовательной программе. Однако в случае мониторов, тела процедур должны быть защищены от повторного входа и реализовываться как критические секции. Группирование в тексте критических секций вместе с данными, которые они модифицируют, представляется лучшим, чем рассредоточение критических секций по всей программе пользователя, как описано в [7, 12]. Оно также соответствует традиционной практике написания супервизоров операционных систем. Это можно рекомендовать безоговорочно.

Однако, гораздо труднее убедиться в полезности понятия условия как примитива синхронизации. Простейшее в использовании средство синхронизации - это, вероятно условное ожидание [2,12]:

wait(B);

где B - обычное булево выражение (wait заставляет данный процесс ждать, пока B не станет истинным); но оно может быть слишком неэффективно для общего использования в операционных системах, потому что его выполнение требует заново оценивать выражение B после каждого выхода из процедуры монитора. Переменная условия дает программисту лучший контроль над эффективностью и планированием; это понятие было разработано, так, чтобы быть очень примитивным, и иметь простое правило доказательства. Но, возможно, некоторый другой компромисс между удобством и эффективностью мог бы быть лучше. Вопрос о том, должна ли операция signal всегда быть последней операцией процедуры монитора, все еще открыт. Эти проблемы будут изучаться и воплощаться в пилотном проекте операционной системы, получившем в настоящее время поддержку Научно-исследовательского Совета Великобритании.

Другим вопросом, который будет изучаться, будет вопрос непересекаемости мониторов. Можно ли проектировать отдельный изолированный монитор для каждого вида ресурсов, так, чтобы он принимал решения о планировании этого ресурса, используя только минимальную информацию о состоянии этого ресурса, и не используя никакой информации о состоянии любого ресурса, управляемого другими мониторами? В принципе, казалось бы, что чем больше знаний о состоянии всей системы мы имеем, тем должно быть проще принимать решения, близкие к оптимальным. Кроме того, в принципе, независимое планирование различных видов ресурсов может привести к тупику. Эти соображения могут привести к проекту традиционного "монолитного" монитора, поддерживающего большие системные таблицы, к которым ко всем можно обращаться и модифицировать их из любой процедуры монитора.

Нет никаких априорных причин для того, чтобы попытка разбить функции операционной системы на ряд изолированных непересекающихся мониторов оказалась успешной. Она может быть успешной только, при разработке и внедрении хороших алгоритмов планирования в каждом мониторе. Чтобы избегать нежелательных взаимодействий между отдельными алгоритмами планирования, представляется необходимым соблюдение следующих правил:

1. Никогда не стремитесь сделать оптимальное решение; просто стремитесь избегать постоянного принятия пессимистических решений.
2. Не стремитесь представлять потребителя с виртуальной машиной, которая лучше, чем реальные аппаратные средства; просто стремитесь отразить скорость, размер, и плоскую структуру простых неоптимизированных аппаратных средств.
3. Используйте вытесняющие методы вместо невытесняющих везде, где только это возможно.
4. Используйте методы "ускорения времени" [9] методов, чтобы гарантировать независимость от cтратегий планирования.
5. Сохраняйте низкую дисперсию (также, как и низкое среднее значение) времени ожидания.
6. Избегайте фиксированных приоритетов; вместо этого, старайтесь гарантировать, что выполнение каждой программы в системе продвигается примерно равномерно. В частности, избегайте неопределенного откладывания.
7. Гарантируйте, что, когда требования на ресурсы превзойдет их предложение (то есть, в режиме перегрузки), поведение планировщика будет удовлетворительным (то есть, исключается треш).
8. Определите корректные и разумные правила использования запросов к монитору и предполагайте, что программы пользователя выполняют их условия. Любые необходимые проверки должны выполняться не центральным монитором с общим доступом, а лучше алгоритмом (называемым "оболочкой пользователя") который является локальным для каждого процесса, выполняющего программу пользователя. Этот алгоритм должен быть реализован, по крайней мере частично, в аппаратных средствах (например базовые и граничные регистры, свойства механизма трансляции адресов и т.д.).

Эти возможности построения отдельных мониторов для различных целей, и отделения решений планирования, реализованных в мониторах, от проверки, реализованной в оболочках потребителя, могут давать надежду на то, что мониторы являются подходящим понятием для структурирования операционной системы.

Благодарности. Разработкой концепции монитора я обязан частым дискуссиям и переписке с E. W. Dijkstra и P. Brinch- Hansen. Монитор соответствует "секретарю", описанному в [9], и также в [1,3].

Также благодарность за поддержку - IFIP WG. 2.3., которая обеспечивает место встречи, в котором эти и многие другие идеи возникли, развивались и проверялись.